Great story! What gets us from 95% to 100%? :)
> On 1 Jul 2016, at 05:33, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> On Jun 30, 2016, at 13:36, Taras Zakharko via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On 30 Jun 2016, at 22:11, Austin Zheng <austinzh...@gmail.com> wrote: >>> >>> As for the label semantics, Swift's current behavior is actively >>> misleading, please see the example in the prior email. There are no >>> meaningful semantics in the label, because implicit conversion between >>> differently-labeled function types means that there is no way to usefully >>> enforce these invariants to begin with. >> >> That is a good point. I admit to not knowing this (I strongly expected that >> labels would be semantically meaningful). But what exactly is the status of >> the argument labels than in Swift? Just a documentation device for the >> programmer and a hint for the compiler to do function dispatch? But if the >> compiler indeed does dispatch on argument labels, then they are not >> completely void of semantics, are they? As I mentioned before, I think the >> problem here is much deeper. >> >> The state of affairs I would prefer is something along these lines: >> >> 1. Labels are semantically meaningful >> 2. There is an explicit casting system for function signatures >> 3. This casting system should be in close correspondence to tuples. The >> "function argument lists look sort of like tuples“ is a very compelling >> reason actually, because of the principle of the least surprise. If I have >> two things in the language that look very similar, then its very confusing >> if they exhibit very different behaviour. Again, I am not proposing that >> one goes back to model functions in terms of tuples. But as long as there is >> a surface resemblance (and an obvious morphisms between the two), at least >> some aspects of their design should be kept in sync. >> >> But again, this touches on some deep design decisions for the language, so I >> — as an amateur — don’t feel in my plate discussing this here. I believe >> that there currently might be some inconsistencies in the language design >> that should be sealed with (but maybe they are no inconsistencies at all and >> I simply have false expectations). > > Language history, a.k.a. story time! > > We started out with the “perfect” model of a function type being a map from a > tuple to a tuple. Different argument labels were just overloads. It really > was quite a simple model, other than not having 1-tuples. Well, and variadics > and default values and trailing closures didn’t make sense anywhere but in > functions, but still. Very simple. > > (And inout. And autoclosure. And maybe a few more.) > > Then we hit a snag: naming guidelines. We wanted argument labels to be > something people felt comfortable using, something that would be encouraged > over a sea of unlabeled arguments. But even before the Swift 3 naming > conventions were hammered out, the natural names for argument labels didn’t > seem to match the names you’d want to use in the function. So we split the > names of parameters off from the names of tuple elements. > > (This was precipitated by wanting to import Objective-C methods, but I think > it would have come up regardless.) > > As seen earlier in the thread, argument labels don’t make for good tuple > element labels. Especially with the Swift 3 guidelines, argument labels > usually don’t make sense without the context provided by the base name, and > two methods that happen to share argument labels might not actually be very > similar, while two methods that are duals of each other might have different > argument labels due to, well, English (e.g. 'add(to:)' vs. 'remove(from:)’). > > The real blow, however, came with that very first idea: that we could treat > methods with different argument labels as simple overloads in type. This led > to poor diagnostics where the compiler couldn’t decide whether to believe the > types or the argument labels, and might tell you you have the wrong argument > labels rather than a type mismatch. For pretty much every Apple API, this was > the wrong decision. On top of all that, it was really hard to refer to a > method when you didn’t want to call it. (Most methods with the same base name > still have unique labels, so you don’t need the types to disambiguate.) > > So we introduced the notion of “full names”, which are the things you see > written as ‘move(from:to:)` (and which are represented by DeclName in the > compiler). Almost immediately diagnostics got better, testing optional > protocol requirements got shorter, and a lot of compiler implementation got > simpler. > > And then we kind of got stuck here. We have full names used throughout the > compiler, but tuple labels still appear in types. They’re still used in > mangling. We got rid of the “tuple splat” feature, but still model > out-of-order arguments as “tuple shuffles”. And we allow a number of > conversions that look like they should be invalid, but aren’t. > > (And it’s important that we continue allowing them, or at least some of them, > because we want to be able to pass existing functions to things like map and > reduce without worrying about conflicting labels.) > > So we’ve given up the perfect ideal of tuple-to-tuple. But we did it because > we value other things more than that ideal: variadics, default values, > trailing closures, inout, autoclosure, distinct argument labels and parameter > names, referencing a function by full name, and diagnostics that better match > the user’s likely intent (particularly given the naming guidelines and > existing libraries). I think that’s a worthwhile trade. > > Jordan > > P.S. Anyone is allowed to think this is not a worthwhile trade! But part of > the purpose of this story is to show that we’re already 90% of the way > towards making tuples and function arguments completely separate, even if > they have similar syntax. This proposal gets us to maybe 95%. > > > _______________________________________________ > 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
