Just adding this here for reference: func foo(_: Void) {} func bar() {} // All these compile in Swift 3: foo() foo(()) bar() bar(()) // But only these two compile in Swift 4: foo(()) bar()
On Mon, Jun 12, 2017 at 9:44 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Mon, Jun 12, 2017 at 2:32 PM, Jérémie Girault < > jeremie.gira...@gmail.com> wrote: > >> @xiaodi >> I disagree on many points, for example what is the type of x when we type >> `let x = *Void` ? >> > > That would not be a legal statement. Exploding a tuple is an operation > that only makes sense inside an argument list. Likewise `let x = &Void` > will not compile. > > >> 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). >> > > I'm not sure I understand your motivation. Void is just a typealias. If > tomorrow Void meant something else, all functions must still return (), and > there is still no implicit tuple splatting. > > >> 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 >> > > Indeed, that's the result of SE-0110; these parentheses are needed because > there is no implicit tuple splatting. They would be required even if `Void` > did not exist in the language at all. > > >> >> — >> 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution