[swift-evolution] [Proposal] Change Void meaning

[Anders Ha]

Just want to note that `Void` aka empty tuple is still constructible, so it doesn’t exactly mean “no value” but only “an occurrence without a substantial value”, especially when a stream of voids in FRP can be used as a trigger.

To exactly represent “no value”, inhabitable types like `Never` are better as they statically guarantee that no instance would ever exist.



Regards,
Anders

> On 13 Jun 2017, at 3:05 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Unfortunately, I think this proposal appears to be mistaken as to this key premise: Void was never (IIUC) meant to model the absence of arguments; it is a type with one possible value.
>> 
>> If I recall, a number of conversations have been raised about Void being a typealias of (), and the definitive response has been that this falls into the ship-has-sailed category of out-of-scope changes.
>> 
>> More generally, the recent spate of complaints about regressions to a particular coding style have to do with loss of implicit tuple splatting, the cure for which is a proper implementation of tuple splatting, not poking holes into settled parts of the type system.
> 
> But you can’t deny that SE-0110 has also caused regressions in the use of Void as generic argument because Void is modelled as the empty tuple. And tuple splatting will not fix those regressions.
> 
> And contrary to what some people might think, this is not an “edge-case”. Most useful monads modelled with generics have good reasons to use Void:
> 
> The Result<T> monad: Result<Void> represents the result of an operation with no return value
> The Promise<T> monad: Promise<Void> represents the result of an asynchronous operation with no return value
> The Observable<T> monad (in functional reactive programming): Observable<Void> represents a stream of events with no values
> 
> I use all three monads in my code and I’ve had to modify a lot of code when migrating to Swift 4 beta1 because of Void.
> 
> David.
> 
>> On Mon, Jun 12, 2017 at 12:15 John McCall via swift-evolution <swift-evolution at swift.org> 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.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution