[swift-evolution] [Proposal] Change Void meaning

[Jérémie Girault]

At the moment I’m only considering the zero-cardinality tuple and don’t
want to address the implicit destructuring issues.
Therefore you are right with foo(fnA) and foo(fnB); but foo(fnC) won’t
compile.

My goal is to add small propositions with simple rules to have better
compatilibty and a more natural way to approach the code.
This could be addressed by another proposition (not on this topic)

—
very short reply expected - vsre.info
Jérémie Girault

On 12 juin 2017 at 19:03:51, Jens Persson (jens at bitcycle.com) wrote:

I have just had a quick look but I'm interested in what you think about the
following example, which currently behaves like the comments say:

func foo<A>(_ fn: (A) -> Void) {}
func fnA() {}
func fnB(_ a: Int) {}
func fnC(_ a: Int, _ b: Int) {}
foo(fnA) // Compiles in Swift 3, error in Swift 4
foo(fnB) // Compiles in both Swift 3 and Swift 4
foo(fnC) // Compiles in Swift 3, error in Swift 4

>From what I read in your proposal, I assume that you want foo(fnA) to
compile in both.
But if so, don't you think foo(fnC) should also compile in both?

/Jens


On Mon, Jun 12, 2017 at 10:48 AM, Jérémie Girault via swift-evolution <
swift-evolution at 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. If this is no
> more the case, then it’s no more a reason to keep Void as an empty tuple.
>
> 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
> 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/0477216d/attachment.html>