> On Dec 23, 2015, at 9:14 , Joe Groff via swift-evolution 
> <[email protected]> wrote:
> 
>> 
>> On Dec 23, 2015, at 7:36 AM, D. Felipe Torres via swift-evolution 
>> <[email protected] <mailto:[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.

One of the primary reasons we have the "regions" in Objective-C is because we 
have existing large bodies of code that need to be audited and annotated. The 
intent there is to set up a reasonable default, and just mark that a particular 
section follows that default, rather than to have some code inside regions and 
some code outside.

Jordan

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to