[swift-evolution] Pitch: Partial Implementations

[Vladimir.S]

On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote:
>
>> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>
>> MOTIVATION:
>>
>> In current Swift, a pattern has emerged among some developers, in
>> order to logically group parts of a class or struct’s declaration,
>> particularly around protocols:
 >> ...
>>
>> What do you think?
>
> If we wanted to allow code like this to be written we wouldn’t need a
> new keyword to do it.  You are proposing two things here:
>
> 1) Allow stored properties in same-module extensions.  This has been
> discussed in the past and is a possibility, but I suspect it is not in
> scope for consideration during Swift 4.

Are we really expect to have stored properties in same-module extensions?
As I remember, there a lot of questions were raised during discussions so 
for some reason *I* had a feeling that we should not expect this happens in 
near feature. Probably I missed something.

FWIW I really like the *feature* proposed to structure declaration of my 
type as I want/need, this leads to more clear and separated code which(at 
declaration level) supports "single responsibility" principle.

I too think that proposed feature should be solved by extensions where 
stored properties are allowed(instead of separate syntax), *but* I believe 
we can(should) have the proposed feature even before we allow(if?) stored 
properties for same-module extensions: allow them for extensions in the 
same *file* only.

It seems like currently file is treated as code unit(especially when we are 
reverting back meaning of 'private' to same-file), which should be 
controlled by single person or contains not too complex logic so can be 
supported by different developers, inside which details should not be 
hidden and "you know what you do". So, IMO it will be naturally if compiler 
allows stored properties for extensions in same file with type declaration 
and treat these extensions just as partial class declaration.

 > 2) Change the meaning of
> `private` to not mean lexical scope anymore, but instead be lexical
> scope or an extension of the type introducing the lexical scope in the
> same module.  Changes to access control other than the proposal
> currently under review are out of scope for Swift 4.
>
>
>>
>> Charles
>>
>> _______________________________________________ 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
>