@xiaodi I disagree on many points, for example what is the type of x when we type `let x = *Void` ? This is the essence of the problem and this proposition wants to solve this.
The regression is due to both reason combined : typealias Void = () AND SE-0110 My proposition is to change the meaning of Void from () to “something else” that is type-compatible with SE-0110 (and splatting in the future). If you want an example of the changes needed to migrate to swift4, just look at the 42 files of handling parenthesis PR of RxSwift needed for swift4 upgrade : https://github.com/ReactiveX/RxSwift/pull/1282/files — very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 21:18:06, Xiaodi Wu (xiaodi...@gmail.com) wrote: On Mon, Jun 12, 2017 at 2:05 PM, David Hart <da...@hartbit.com> 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. > I'm not sure I understand this statement. Void is a synonym for the empty tuple, and that hasn't ever changed, so it can't be the root cause of any regressions. > And tuple splatting will not fix those regressions. > How come? If `*` is the splat operator, then it would be legal to call a function `foo` that takes no arguments with `foo(*Void)`; if implicit tuple splatting returns in fully implemented form, then it would be legal to call it once again with `foo(Void)`. 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. > Can you give examples of the modifications needed during migration? From here, I can only see that the reason any code needs modification is the complete removal of implicit tuple splatting. Nothing has changed about Void being a synonym for the empty tuple; even if you rename Void, functions will still return () by some other name, and unless there is tuple splatting in some form, the migration you performed is inevitable. 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
