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.
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
Jérémie Girault
On 12 juin 2017 at 22:06:54, Xiaodi Wu (xiaodi.wu@gmail.com) wrote:
On Mon, Jun 12, 2017 at 2:56 PM, Jérémie Girault <jeremie.girault@ >> 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.wu@gmail.com) wrote:
On Mon, Jun 12, 2017 at 12:44 Jérémie Girault <jeremie.girault@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.wu@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