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
<[email protected]> 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 [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing
list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
