[swift-evolution] Pitch: Partial Implementations
svabox at gmail.com
Thu Mar 23 16:10:58 CDT 2017
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:
>> 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.
>> _______________________________________________ swift-evolution
>> mailing list swift-evolution at swift.org
> _______________________________________________ swift-evolution mailing
> list swift-evolution at swift.org
More information about the swift-evolution