On Mon, Jun 12, 2017 at 3:04 PM, Jérémie Girault <jeremie.gira...@gmail.com> wrote:
> 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. > Yes, it requires compiler support. > 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.girault@ > 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