[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