Exactly, that means that your implementation of the tuple splatting operator is out of the type system. Can you expose it’s signature ?
If you want the operator to be “compiler-magic” it’s possible. This proposal is an alternate solution. My point is that updating Void according to this proposal would - preserve the type system in a better way - have better source compatibility (in time for swift 4 release, were we probably won’t see tuple splatting) - also keep the elegant original syntax of swift instead of stacking parenthesis The impact for code writers would be minimized on time for swift 4 release As for return values: this proposition does not intend to change the how return value of Void functions works. — very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 21:45:08, Xiaodi Wu (xiaodi...@gmail.com) 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
