[swift-evolution] [Proposal] Change Void meaning

[Jérémie Girault]

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 (svabox at gmail.com) 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170612/db2e4346/attachment.html>