Since we’re moving this to a new thread, I’ll copy forward the design guidance that Chris Lattner gave us.
Chris wrote a wealth of far-ranging thoughts on Swift’s design philosophy. I wrote: > I’ll copy and paste what Chris wrote into a “Swift philosophy” checklist for > Brent’s proposal, and for any others working toward these goals. Chris, > please correct me if I’m putting words in your mouth! > Provide a programmer model that: > is high level > is expressive and clean > is dynamic by default > doesn’t require a programmer to think about the fact that a static compiler > is able to transparently provide great performance > Provide a performance model that: > is predictable > makes the dynamic parts of the language optimizable by a static compiler in > many common cases > does not requiring profiling or other dynamic information > does not require JIT compilation And Chris wrote: > Yes, this is a good summary. I think that guidance from Chris could help focus this discussion. I’d also like to hear more thoughts on Kevin’s proposal from a broader range of people. Cheers, Paul > On Jan 4, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> Didn't we already have a very long discussion about all of this? > > We did, which ended with you and I clearly in fundamental disagreement, while > others appeared to think it was a good idea. I'm now putting forth a more > specific version of that proposal, one that I think is almost ready for > review. > >> It's confusing, it's overloading the term `final` in a way that doesn't seem >> to make sense (`final` means you can't subclass or override, but there's >> nothing in this proposal that affects either subclassing _or_ method >> overriding) > > `final` is currently restricted to the context of a class, yes. But I think > it's a clean extension of the concept to use it to mark protocol extension > methods that can't be overridden. Hence why I provide this re-definition of > the meaning of `final`: > > `final` declares that subtypes of this type must use this specific > implementation of the member, and cannot substitute their own specialized > implementation. Attempting to do so causes an error. > > (Technically it's true that no protocol extension member can be overridden. > But the distinction between defaulted protocol members and protocol extension > members is very subtle—they are both written in protocol extensions and look > identical unless you go back to the protocol definition to check what's > there—and I think it needs to be called out in the text of the code.) > >> and it means protocol extensions that you aren't even aware of from other >> modules can cause your otherwise-legal type to start throwing errors. > > > You can only get a conflict from something that's visible to your code. For > instance, an `internal` protocol extension in another module can't cause a > conflict—only public APIs can cause conflicts through imports. And it's > important that they do, because it's hard to know that you didn't think the > conflicting member was a defaulted protocol requirement you could override. > >> Making this kind of change only makes any sense at all if you assume that, >> every single time someone implements a method that happens to look the same >> as a method provided by a protocol extension, they're trying to override >> that protocol extension method. But since protocol extension methods cannot >> be overridden (merely shadowed), that assumption doesn't make a lot of sense. > > I realize that this doesn't confuse you, but it seems to confuse everyone > else. The core team seems to think so too, because they consider the lack of > a warning about it to be a bug that can be fixed without going through the > evolution process. (And I believe there's a thread currently in swift-dev > where someone is working on that warning.) > >> and I think forcing people to brand their legitimate functions with a >> negative-sounding term "incoherent" is also basically subtly punishing >> people. I mean, who wants to write code that is publicly branded as being >> "incoherent" code? > > > "Incoherent" is a very opinionated keyword. But I think it's also a > descriptive one, which captures in a single word why you may not want to use > it. I'm open to alternatives, including less judgmental alternatives. > >> Also, even after reading this proposal, it's still not obvious to me how the >> @incoherent attribute works. The rest is a little confusing, but this >> attribute is very confusing all by itself. > > `@incoherent` basically says "I know what I'm doing, so don't emit errors > about conflicts between these two types; just give me the Swift 2.1 > behavior". I'm not sure why you think the current behavior is not confusing, > but `@incoherent`'s behavior is very confusing. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
