Interesting use-case, Actually, after double-checking the rules I proposed, it seem to be possible, to do `let x: Void = foo()` but all “pseudo-instances” of Void would be stripped at compile time. Therefore this does not introduces source-breaking changes even if this use case is quite convoluted (but could happen easily in generics case).
I do not propose that implicit Void should be removed, it’s more of a sample of the “magic” around Void. My proposition consist to “extend" this magic a bit using given rules and in consequence, allow more source-compatibility, readability. I just read the SE-0066 and don’t see any conflicting point (nor relation) with this proposition. https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md If you see any conflicting point, I would be interested to know which one specifically. — very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 13:21:24, Vladimir.S ([email protected]) wrote: On 12.06.2017 11:48, Jérémie Girault via swift-evolution 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. If this is no more the case, then > it’s no more a reason to keep Void as an empty tuple. Could you clarify, do yo propose to change meaning of this code: func foo() {} from "implicitly returns Void" to "returns nothing" ? So, this valid Swift 3 and Swift 4 code will be invalid: func foo(){} let x : Void = foo() ? In this case I believe your proposal introduces new source breaking change that makes transition from Swift 3 to Swift 4 even more difficult for some code. There were short discussions in this list if implicit Void return should also be removed and IIRC was rejected by common opinion or by some one's authoritative opinion. Also, I'd like to suggest you to read text of SE-0066 proposal, where you can see that it clearly separated functions accepting Void parameter and accepting no parameters. So, IMO you should also refer to SE-0066 proposal in your text and it seems(correct me if I understood your proposal incorrectly) you should propose to revisit SE-0066 in this detail. Vladimir. > > I think that by having a few rules around tuples of cardinality 0 and 1 and also > arguments list, we could greatly improve source compatibility and keep a lot of what > makes swift great when using functional style and generics. > > I drafted a proposal that would allow more source compatibility and type consistency > and would enjoy discussing it with you, in order to improve it : > > https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md > > Let me know what you think about it, > > — > very short reply expected - vsre.info <http://vsre.info> > Jérémie Girault > > > _______________________________________________ > 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
