[swift-evolution] [Proposal] Change Void meaning

[Jérémie Girault]

- Void as arguments is pretty common when using generics, that’s a core
point of this proposal. An maybe that’s why we misunderstood ourselves
(around 0110 / 0066). This proposal addresses arguments.
- maybe it should be revised around this ? Simple example :

`typealias Callback<T> = (T) -> Void` -> `Callback<Void>` will give `(Void)
=> Void`.

It was acceptable before swift4 but no more. However nobody cares about
this `Void` argument and actually we know it’s value. So why let the
developer type it ?

My point here is that `Void` should be “striped” by “reducing” argument
list signatures.

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

On 12 juin 2017 at 19:15:18, John McCall (rjmccall at apple.com) wrote:


On Jun 12, 2017, at 4: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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170612/b183b2a3/attachment.html>