On 12.06.2017 21:04, Xiaodi Wu via swift-evolution 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.
Actually *SE-0066* determinate this first:
(code example in *Proposed solution* section)
let f: () -> Int // function with no parameters
let g: (()) -> Int // function taking a single () parameter
let h: ((())) -> Int // function taking a single () parameter
f(); g(()); h(()) // correct
f(()); g(); h() // errors
Seems like it's just SE-0066 *more correctly* implemented in Swift 4 *in addition* to
SE-0110 implementation.
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
_______________________________________________
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
