Still I don’t understand your point about SE-0066, and maybe we are not
talking about the same thing ?
This new proposal basically tries to address that in Swift4 :
`func foo() {}` is different from `func foo(Void) {}`, and cannot be
coerced.
That does not seem a natural thing from the developer point of view.
This is a consequence of
1/ SE-0110 specifying that function arguments-as-tuple exist no more and
are differentiated from tuple-as-arguments
2/ the fact that Void is historically a tuple
This new proposition tries to address regressions happening when arguments
are “Void” only.
—
very short reply expected - vsre.info
Jérémie Girault
On 12 juin 2017 at 19:15:18, John McCall (rjmcc...@apple.com) 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
