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@swift.org> wrote: > >> >> On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution >> <swift-evolution@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@swift.org> wrote: >> >>> On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution >>> <swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
