[swift-evolution] Analysis of existing scopes

[Matthew Johnson]

> On Feb 23, 2017, at 1:34 PM, Joanna Carter <joanna at carterconsulting.org.uk> wrote:
> 
> 
>> Le 23 févr. 2017 à 14:59, Matthew Johnson <matthew at anandabits.com> a écrit :
>> 
>> The rationale for this is that it allows you to explore the eventual design of a type without exposing it.  When you are confident in the design all you need to does modify the access modifier of the type itself.  Without this capability people might resort to comments indicating the intended future visibility and then have to remember to go back and convert all of those comments into the new access modifier when you’re ready to publish the type.
> 
> I suppose I can understand that but...
> 
> Certainly you can check that everything compiles but how does it help if you want to test the code does what you expect? What about testing the validity of inheritance controls?
> 
> Personally, I test new ideas in a "side" project before integrating into the main project. That say, I get to develop everything at the correct visibilities and with everything ready to just copy and paste to the main project.

Sometimes APIs are used internally in production while eventually planned for public visibility.  New features in Apple’s frameworks often start life this way.

> 
>> The important thing to keep in mind is that software isn’t a fixed, static thing.  It evolves over time.  This is a tool to help grow software over time.
> 
> After over 25 years of developing software and teaching others, I have never heard of such a justification of such a mish-mash of visibilities. This might seem like a good idea for testing but, what about the effect of it on real development where inexperienced developers keep on finding that visibilities that are "possible" don't actually work?

I don’t have a strong feeling about this particular capability.  I’m just trying to state the rationale as I understand it.

> 
> --
> Joanna Carter
> Carter Consulting
>