> On 2016-07-20, at 19:34, John McCall <rjmcc...@apple.com> wrote:
>
> I agree that having the concept of "visible publicly but only arbitrary
> modifiable internally" adds complexity to the language. However, once we've
> got non-open public classes — and as I understand it, you still support those
> — that complexity already exists. You're not really eliminating anything by
> preventing this from being applied to methods.
>
> Also, we're going to be proposing a lot of new things for library-resilience
> over the next six months or so that will add appreciable but unavoidable
> complexity to the language around module boundaries. Module boundaries have a
> lot of special significance in the language design because Swift takes the
> stable binary interface problem much more seriously than, I think, almost any
> other language can claim to.
Fair enough! Let’s move on.
>> This reminds me: Whether or not we allow the sealed level on methods, I
>> suggest we provide a contextual keyword to (optionally) spell it. A "sealed"
>> keyword is the obvious choice. This would encourage people to use common
>> terminology, and makes it easier to use search engines to find an
>> explanation of the concept. Autogenerated API summaries should add the
>> "sealed" keyword.
>
> Yes, we should probably add some way to spell it. "sealed" does not feel
> like a natural opposite to "open", however, and I think we're quite taken
> with "open". I would suggest "nonopen" or "closed”.
Ah, interesting! Kotlin and Scala uses the “sealed” keyword for their own
variants for the same concept. C# is popular and uses “sealed” to mean what we
call “final”; it’s in the same general ballpark. MATLAB (!!!) does the same. So
it can be argued “sealed" is a somewhat common term of art for roughly this
pattern.
I could get used to “closed”, though.
But I think “nonopen” is a no-no (pen): it makes my eyes bleed.
--
Károly
@lorentey
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
