<div dir="ltr">This: <a href="https://twitter.com/slava_pestov/status/874394132340289536">https://twitter.com/slava_pestov/status/874394132340289536</a><div>seems to suggest that the current Swift 4 behavior will not change much in this domain. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 1:11 AM, Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12.06.2017 23:17, Jens Persson via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think this proposal would be complicating rather than simplifying the type system, it would be adding a special rule.<br>
And it is not a step towards resolving the many parentheses-related inconsistencies that still remain.<br>
<br>
Here is an example of one such remaining inconsistency, it's still in (latest dev snapshot) Swift 4, so this is the behavior of both Swift 3(.2) and 4:<br>
func foo() -> Void {}<br>
func foo(_: Void) -> Void {} // This is OK<br>
func bar(fn: () -> Void) {}<br>
func bar(fn: (_: Void) -> Void) {} // ERR: Invalid redecl.<br>
<br>
I think the least surprising behavior here would be no error, rather than two.<br>
The current behavior with one error is very surprising.<br>
</blockquote>
<br></span>
As I understand, currently in Swift 4 there are a number of bugs related to function types, so I believe it is incorrect to make conclusions based on current behavior of Swift 4 code. I've asked John McCall in this thread about *planned* behavior of some Swift 4 release code related to function types, let's see what will be the reply.<br>
<br>
(I'd suggest to create a bug on <a href="http://bugs.swift.org" rel="noreferrer" target="_blank">bugs.swift.org</a> for this particular issue - probably this will help to improve Swift 4 compiler)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Mon, Jun 12, 2017 at 10:09 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
<br>
On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.<wbr>com</a>>> wrote:<br>
<br>
Exactly, that means that your implementation of the tuple splatting operator<br>
is out of the type system.<br>
Can you expose it’s signature ?<br>
<br>
If you want the operator to be “compiler-magic” it’s possible. <br>
<br>
Yes, it requires compiler support.<br>
<br>
This proposal is an alternate solution.<br>
<br>
My point is that updating Void according to this proposal would<br>
- preserve the type system in a better way<br>
- have better source compatibility (in time for swift 4 release, were we<br>
probably won’t see tuple splatting)<br>
- also keep the elegant original syntax of swift instead of stacking<br>
parenthesis<br>
<br>
The impact for code writers would be minimized on time for swift 4 release<br>
<br>
As for return values: this proposition does not intend to change the how<br>
return value of Void functions works.<br>
<br>
—<br></span>
very short reply expected - <a href="http://vsre.info" rel="noreferrer" target="_blank">vsre.info</a> <<a href="http://vsre.info" rel="noreferrer" target="_blank">http://vsre.info</a>><span class=""><br>
Jérémie Girault<br>
<br>
On 12 juin 2017 at 21:45:08, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a><br></span>
<mailto:<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>) wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault<<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.<wbr>com</a><br></span>
<mailto:<a href="mailto:jeremie.girault@gmail.com" target="_blank">jeremie.girault@gmail.<wbr>com</a>>>wrote:<span class=""><br>
<br>
@xiaodi<br>
I disagree on many points, for example what is the type of x when we<br>
type `let x = *Void` ?<br>
<br>
<br>
That would not be a legal statement. Exploding a tuple is an operation that<br>
only makes sense inside an argument list. Likewise `let x = &Void` will not<br>
compile.<br>
<br>
This is the essence of the problem and this proposition wants to solve<br>
this.<br>
<br>
The regression is due to both reason combined : typealias Void = () AND<br>
SE-0110<br>
<br>
My proposition is to change the meaning of Void from () to “something<br>
else” that is type-compatible with SE-0110 (and splatting in the future).<br>
<br>
<br>
I'm not sure I understand your motivation. Void is just a typealias. If<br>
tomorrow Void meant something else, all functions must still return (), and<br>
there is still no implicit tuple splatting.<br>
</span></blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
If you want an example of the changes needed to migrate to swift4, just<br>
look at the 42 files of handling parenthesis PR of RxSwift needed for<br>
swift4 upgrade : <a href="https://github.com/ReactiveX/RxSwift/pull/1282/files" rel="noreferrer" target="_blank">https://github.com/ReactiveX/R<wbr>xSwift/pull/1282/files</a><br>
<<a href="https://github.com/ReactiveX/RxSwift/pull/1282/files" rel="noreferrer" target="_blank">https://github.com/ReactiveX/<wbr>RxSwift/pull/1282/files</a>><br>
<br>
<br>
Indeed, that's the result of SE-0110; these parentheses are needed because<br>
there is no implicit tuple splatting. They would be required even if `Void`<br>
did not exist in the language at all.<br>
<br>
<br>
—<br></span>
very short reply expected -<a href="http://vsre.info" rel="noreferrer" target="_blank">vsre.info</a> <<a href="http://vsre.info" rel="noreferrer" target="_blank">http://vsre.info</a>><span class=""><br>
Jérémie Girault<br>
<br>
On 12 juin 2017 at 21:18:06, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a><br></span>
<mailto:<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>) wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mon, Jun 12, 2017 at 2:05 PM, David Hart<<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a><br></span>
<mailto:<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>>>wro<wbr>te:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution<br></span><div><div class="h5">
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
<br>
Unfortunately, I think this proposal appears to be mistaken as to<br>
this key premise: Void was never (IIUC) meant to model the<br>
absence of arguments; it is a type with one possible value.<br>
<br>
If I recall, a number of conversations have been raised about<br>
Void being a typealias of (), and the definitive response has<br>
been that this falls into the ship-has-sailed category of<br>
out-of-scope changes.<br>
<br>
More generally, the recent spate of complaints about regressions<br>
to a particular coding style have to do with loss of implicit<br>
tuple splatting, the cure for which is a proper implementation of<br>
tuple splatting, not poking holes into settled parts of the type<br>
system.<br>
</div></div></blockquote><div><div class="h5">
<br>
But you can’t deny that SE-0110 has also caused regressions in the<br>
use of Void as generic argument because Void is modelled as the<br>
empty tuple.<br>
<br>
<br>
I'm not sure I understand this statement. Void is a synonym for the<br>
empty tuple, and that hasn't ever changed, so it can't be the root<br>
cause of any regressions.<br>
<br>
And tuple splatting will not fix those regressions.<br>
<br>
<br>
How come? If `*` is the splat operator, then it would be legal to call<br>
a function `foo` that takes no arguments with `foo(*Void)`; if<br>
implicit tuple splatting returns in fully implemented form, then it<br>
would be legal to call it once again with `foo(Void)`.<br>
<br>
And contrary to what some people might think, this is not an<br>
“edge-case”. Most useful monads modelled with generics have good<br>
reasons to use Void:<br>
<br></div></div>
*The Result<T> monad:*Result<Void> represents the result of an<span class=""><br>
operation with no return value<br></span>
*The Promise<T> monad:*Promise<Void> represents the result of an<span class=""><br>
asynchronous operation with no return value<br></span>
*The Observable<T> monad (in functional reactive<br>
programming):*Observable<Void> represents a stream of events with<span class=""><br>
no values<br>
<br>
I use all three monads in my code and I’ve had to modify a lot of<br>
code when migrating to Swift 4 beta1 because of Void.<br>
<br>
<br>
Can you give examples of the modifications needed during migration?<br>
From here, I can only see that the reason any code needs modification<br>
is the complete removal of implicit tuple splatting. Nothing has<br>
changed about Void being a synonym for the empty tuple; even if you<br>
rename Void, functions will still return () by some other name, and<br>
unless there is tuple splatting in some form, the migration you<br>
performed is inevitable.<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution<br></span>
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Jun 12, 2017, at 4:48 AM, Jérémie Girault via<br>
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br></span><span class="">
<mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
<br>
Hi here,<br>
<br>
As I tested swift4 in xcode9b1 I noticed a lot of<br>
regressions about tuples usage.<br>
<br>
After documenting myself about the changes which happened, I<br>
thought that they could be improved. Instead of fighting<br>
these propositions (which make sense), I wanted create a few<br>
proposal which would improve these recent changes with a few<br>
simple rules.<br>
<br>
My propositions are based on the recent decisions and in the<br>
continuation of SE-0110. The first one is about Void.<br>
Void is historically defined as the type of the empty tuple.<br>
The reason of this is that arguments were initially<br>
considered as tuple.<br>
</span></blockquote><span class="">
<br>
The dominant consideration here was always return types, not<br>
parameters. I'm not sure there was ever much point in<br>
writing Void in a parameter list, but whatever reasons there<br>
were surely vanished with SE-0066.<br>
<br>
Note that 'void' in C was originally exclusively a return<br>
type. ANSI gave it a new purpose it with void*, but the<br>
meaning is totally unrelated.<br>
<br>
John.<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br></span>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><span class=""><br>
<<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailm<wbr>an/listinfo/swift-evolution</a>><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br></span>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailm<wbr>an/listinfo/swift-evolution</a>><br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><span class=""><br>
<<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailm<wbr>an/listinfo/swift-evolution</a>><br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
</span></blockquote>
</blockquote></div><br></div>