> 2016/07/16 21:37、Jean-Daniel Dupas <mail...@xenonium.com> のメール：
>
>> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>
>> 2016/07/15 16:37、Riley Testut via swift-evolution <swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>> のメッセージ:
>>
>>> FWIW, I'm still against this proposal, but since it will be accepted
>>> regardless, here are my thoughts:
>>>
>>> • Open keyword is significantly better.
>>> • Members should be *open* by default, and final should be opt-in. If
>>> you're opening up a class for subclassing, my gut says you should allow the
>>> client to do as they wish.
>> If you have a class that was not open yet, just making it open wouldn't
>> expose any members: it would then just be subclassable.
>>
>> If the act of making the class open doesn't implicitly make overriding
>> possible, well all you can do then is add methods, and that can be done with
>> extensions anyways, so it's not as useful and makes the public open class {}
>> pattern just by itself not so useful imho... 😬
>>
>> Also, the keyword 'open' itself may imply 'hey I'm open, please do what you
>> want with my public members', whereas 'subclassable' is more specific in
>> intention... (but that's just me, so n=1 and all that)
>>
>> TLDR; +1 to the above: simpler is better and defaulting to overridable for
>> public members on an open class is simpler... invariants can be protected by
>> the 'final' keyword.
>>
>> If we were to default to non-overridable, a more consistent 'open' on the
>> method is preferred over overridable for me... open class, open method...
>> much better imho...
>
> Do we really need an open keyword ?
>
> As already said, if open does nothing more than allowing the class to be
> subclassed, why not simply make the class subclassable if it contains at
> least one overridable member ?
Thats a good point actually… but looks like Review #2 has already started… and
'open' is available for both class and method there… I suppose its the whole
"default to safe", just in case someone made one method 'open' they may not
have intended to actually make the whole class open… (also see below)
> In case we require an open keyword, what would happen if someone mark a
> member overridable, but does not make the class open ? Will the compiler emit
> an error, or make the class implicitly « open » ?
In proposal #2 looks like it would generate an error, but Xiaodi Wu has said
that it should be allowed and not generate an error per SE-0025
<https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>.
<https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#complications-with-private-types>Take
a look at
<https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#complications-with-private-types>:
"The compiler should not warn when a broader level of access control is used
within a type with more restrictive access, such as internal within a private
type."
- Andre
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
