[swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson]

Sent from my iPad

> On Feb 17, 2017, at 6:44 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>> Here, a function call is an _intentional_ act. Writing a function not meant to be called is an _intentional_ act. It is strange that you would demand the compiler to stand between two of your own intentional acts.
>> 
>> Yesterday I stated one intention. Today I (or a coworker) act with a contradictory intention.
>> 
>> One of these intentions, or some underlying assumption, must be in error.
> 
> Must it? Contradiction != error. I can simultaneously not want to expose a member as the vendor of the API *and* want to invoke the same member as the consumer of the API. Why must I be in error?
>  
>> Why would I want to rely on a human to notice the error, if I can make the compiler do it?
>> 
>> It is normal to want the compiler to catch my errors. It is strange to prefer finding errors manually.
> 
> I can agree that compilers should catch errors. I want to persuade you that what we are talking about here does not fall into the category of error.

I don't view it so much as an error as I do a great tool to communicate compiler verified intent across time (to future readers and to your future self).  As with many things in programming, the value of this is subjective (or at least subject of plentiful debate).  I personally find it quite useful and it's clear that I am not alone.  On the other hand, it's clear that many people don't find it terribly useful.

> 
>> You might persuade me that the cost (in language complexity) of having the compiler detect the contradiction outweighs the benefit.
>> 
>> But I doubt you can persuade me that the detection has no benefit.
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/0330104a/attachment.html>