> On Jun 13, 2017, at 1:45 AM, Gwendal Roué via swift-evolution > <[email protected]> wrote: > > "Discussing" with Xiaodi is a special experience, isn't it? > > He will bite and misrepresent you and your ideas until you get tired and your > idea has been exhausted to death and diluted in dozens of useless messages. > Don't feed him.
This is uncharitable and inappropriate. John. > > Gwendal > > >> Le 12 juin 2017 à 23:10, Jérémie Girault via swift-evolution >> <[email protected] <mailto:[email protected]>> a écrit : >> >> >> — >> very short reply expected - vsre.info <http://vsre.info/> >> Jérémie Girault >> >> On 12 juin 2017 at 22:34:45, Xiaodi Wu ([email protected] >> <mailto:[email protected]>) wrote: >> >>> On Mon, Jun 12, 2017 at 3:16 PM, Jérémie Girault <[email protected] >>> <mailto:[email protected]>> wrote: >>> I invite you to read the proposal rules again with a fresh mindset and >>> benevolence spirit. >>> It’s my first one and may not be very clear but the rules are >>> straightforward. >>> >>> Especially try to forget that Void is a tuple or anything. >>> Void is Nothing in the programmer’s mind. An instance of Void shouldn’t >>> even exist. >>> >>> Sorry, that's not correct. Void is what's called Unit in other languages. >>> It exists. That is why functions with "no return value" return Void. OTOH, >>> Never does not exist. This discussion was had in great detail during the >>> naming debate over Never. >> >> Let’s put facts in front of correctness assertions. Is Void = Unit in C or >> c++ ? can you create instances of void in java ? you have Void for generics. >> https://en.wikipedia.org/wiki/Unit_type >> <https://en.wikipedia.org/wiki/Unit_type> >> And if you look at assembly, sending void or returning void actually means >> "nothing to push on the stack / nothing to pop”. Seems like having this >> stripping on signatures at compile-time could be great ! >> >> Actually, in my opinion we could discuss naming when we agree that the >> mechanism works, using this name is just a way to not impact the developer >> with code changes. >> >> So either we agree on the fact that the mechanism works and we can move on >> to naming, or we get back on the topic : do you see a flaw in the proposal >> rules ? It elegantly transforms signature arity and provides the programmer >> a natural syntax to express it’s code. >> >>> >>> >>> The proposed meaning of Void is to be a “lack” of arguments. It means that >>> each “Void” argument reduces the arity of the function by one, at its exact >>> position. Especially look at the canonical signature definition, and the >>> proposed rules of reduction. >>> >>> I don't understand why you propose to name this new idea "Void". You're >>> proposing something that's not even a lack of an argument, but an >>> anti-argument, like anti-matter! I'm not sure I understand why this is >>> necessary. It seems to be a very strange workaround for one specific issue >>> arising from disallowing implicit tuple splatting. >> >> >> Look at other languages, when you put Void in functions in C or java, do you >> need to add a value ? Ease of use is important. >> >> You imply that I disagree with splatting were I don’t, let’s not make it >> personal. This proposal is even compatible with tuple splatting ! >> >> The proposal rules seem to work and provides great user value. Let’s try to >> consider this ! >> >>> >>> >>> That proposal, if implemented, would effectively allow `Callback<Void>` to >>> be called without arguments in the context of swift4. >>> >>> — >>> very short reply expected - vsre.info <http://vsre.info/> >>> Jérémie Girault >>> >>> On 12 juin 2017 at 22:06:54, Xiaodi Wu ([email protected] >>> <mailto:[email protected]>) wrote: >>> >>>> On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault >>>> <[email protected] <mailto:[email protected]>> 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 ([email protected] >>>> <mailto:[email protected]>) wrote: >>>>> On Mon, Jun 12, 2017 at 12:44 Jérémie Girault <[email protected] >>>>> <mailto:[email protected]>> 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 <http://vsre.info/> >>>>> Jérémie Girault >>>>> >>>>> On 12 juin 2017 at 19:25:31, Xiaodi Wu ([email protected] >>>>> <mailto:[email protected]>) 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 >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
