On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault <jeremie.gira...@gmail.com> wrote:
> @Xiaodi Wu > Disagree, and we would need the original designer here to help us, but my > understanding of the original meaning of tuples-as-arguments is that when I > define: > `func foo(_ arg0: Any, _ arg1: Any) {}` > I can afterwards “apply” a tuple to a function named `foo` and therefore > execute the function on this tuple. > Calling a function syntax was equivalent to put a tuple next to a function > name: > `foo(42, “hello")` the left-hand is `foo`, the right-hand is `(42, > “hello")` is the tuple. > > The same way if I have > `func foo()` > `foo()` means calling `foo` with argument `()` and there we have our > original `Void` > > That meaning changed recently due to multiple SE implementations actually. > Tuples-as-arguments never shipped in any version of Swift, and the ability to "apply" a tuple like that was removed by SE-0029--the original goal was to implement this change in time for Swift 2.2. > The parenthesis around the call don't have a tuple meaning anymore. > Therefore it breaks a lot of code relying on this feature of the language, > which was quite elegant, but could not handle advanced functions features. > Yes, this is an intentional and approved part of SE-0029. The drawbacks were enumerated in that proposal and were deemed acceptable. > @john: Void can happen easily in parameters due to generics, the easiest > example that breaks with swift4 is > `typealias Callback<T> = (T) -> Void` > here > `Callback<Void>` which is perfectly reasonable introduces Void in the > argument list and forces the caller to introduces an empty partenthesis set > when invoking: > ``` > let foo: Callback<Void> = { } > foo(()) > ``` > `Callback<T> = (T) -> Void` refers to a callback that takes exactly one argument. Since argument lists are not tuples, it is not possible to invoke such a callback with zero arguments, or for that matter with two, three, four, or five arguments. That’s were the proposal shines in my opinion: adapting the meaning of Void > to the current context of swift4 gives back the language the elegant syntax > it had while preserving the type system > I'm not sure what you mean by this. No change in `Void` can cause a function of type (T) -> Void to accept zero arguments: it requires one argument of type T. On 12 juin 2017 at 20:04:18, Xiaodi Wu (xiaodi...@gmail.com) wrote: > > On Mon, Jun 12, 2017 at 12:44 Jérémie Girault <jeremie.gira...@gmail.com> > wrote: > >> Void was the empty tuple because arguments were tuples. >> > > As John explained, that is _not_ correct. Void was not motivated by > anything to do with argument lists. > > So no arguments meant empty tuple. >> >> If we consider the empty tuple to be an argument, then the type for the >> type of empty tuple should be `Unit` >> > > It has been suggested to rename Void to Unit. I do believe it’s on the > commonly rejected ideas list (and if it’s not, it ought to be). > > Void, however, seem naturally fitted for the absence of argument. >> >> Should `func foo(Void)` be different from `func foo()`? >> > > SE-0110 determined that the two should in fact be different. > > I don’t think so. But different from `func foo(Unit)` ? Yes ! >> > > It sounds like your quarrel is with the name of the typealias. I don’t see > how that solves any issues with the loss of tuple splatting. Functions will > still return (), and you foo(()) is not foo(). > > My point here is that we probably won’t have splatting for swift4. >> >> >> But if we consider the type system as a guide, we can consider 3 simple >> set of rules and restore almost 100% source compatibility while keeping the >> improvement of SE-0110 >> - Rules for swift3 tuples-arguments of cardinality zero (Void) in swift 4 >> (this proposition) >> - Rules for swift3 tuples-arguments of cardinality one in swift 4 >> (proposition to be done) >> - Rules for swift3 tuples-arguments of cardinality > 1 in swift 4 >> (proposition to be done) >> >> — >> very short reply expected - vsre.info >> Jérémie Girault >> >> On 12 juin 2017 at 19:25:31, Xiaodi Wu (xiaodi...@gmail.com) wrote: >> >> Unfortunately, I think this proposal appears to be mistaken as to this >> key premise: Void was never (IIUC) meant to model the absence of arguments; >> it is a type with one possible value. >> >> >> >> If I recall, a number of conversations have been raised about Void being >> a typealias of (), and the definitive response has been that this falls >> into the ship-has-sailed category of out-of-scope changes. >> >> More generally, the recent spate of complaints about regressions to a >> particular coding style have to do with loss of implicit tuple splatting, >> the cure for which is a proper implementation of tuple splatting, not >> poking holes into settled parts of the type system. >> >> >> >> >> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> Hi here, >>> >>> As I tested swift4 in xcode9b1 I noticed a lot of regressions about >>> tuples usage. >>> >>> After documenting myself about the changes which happened, I thought >>> that they could be improved. Instead of fighting these propositions (which >>> make sense), I wanted create a few proposal which would improve these >>> recent changes with a few simple rules. >>> >>> My propositions are based on the recent decisions and in the >>> continuation of SE-0110. The first one is about Void. >>> Void is historically defined as the type of the empty tuple. The reason >>> of this is that arguments were initially considered as tuple. >>> >>> >>> The dominant consideration here was always return types, not >>> parameters. I'm not sure there was ever much point in writing Void in a >>> parameter list, but whatever reasons there were surely vanished with >>> SE-0066. >>> >>> Note that 'void' in C was originally exclusively a return type. ANSI >>> gave it a new purpose it with void*, but the meaning is totally unrelated. >>> >>> John. >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution