[swift-evolution] "Assume" directive for classes and methods

Joe Groff jgroff at apple.com
Wed Dec 23 11:14:34 CST 2015


> On Dec 23, 2015, at 7:36 AM, D. Felipe Torres via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I've been reading the discussion in "Final by default for classes and methods" and although I don't have a strong position towards what the default behaviour should be, I think a directive to change that behaviour should be added as when nullability was introduced into Obj-C.
> 
> In the current model of Swift, where methods and classes are not final we can ease that by doing something like this:
> 
> ASSUME_FINAL_BEGIN
> class MyClass {
>     func aMethod(arg: String) {
>         
>     }
>     
>     func anotherMethod(number: Int) {
>         
>     }
> }
> ASSUME_FINAL_END
> 
> 
> In this example the whole class is treated as final by the compiler.
> On the other hand, in the following example:
> 
> class MyClass {
> ASSUME_FINAL_BEGIN
>     func aMethod(arg: String) {
>         
>     }
> ASSUME_FINAL_END    
>     func anotherMethod(number: Int) {
>         
>     }
> }
> 
> Only aMethod is final, leaving the rest to the default behaviour. (Ok, the example is not different to prepending 'final' but you get the idea).
> 
> Similarly, should the classes and methods become final by default, a directive to do the opposite should be added (ASSUME_OVERRIDEABLE_(BEGIN|END)?)

We tried to avoid these kinds of contextual blocks because they make reading declarations in isolation much harder. That's one of the reasons we have 'public'/'private' as per-decl modifiers rather than C++/ObjC-style grouping.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/ed0ee8ed/attachment.html>


More information about the swift-evolution mailing list