> On Dec 23, 2015, at 7:36 AM, D. Felipe Torres via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
