[swift-evolution] Pitch: Partial Implementations

[Vladimir.S]

On 24.03.2017 12:50, Haravikk wrote:
>
>> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> 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 <mailto: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.
>
> I can see why some people might want to do stored properties in extensions
> to structure things, but personally I quite like the lack of flexibility as
> it encourages the initial type declaration to focus on what a type
> *contains*, while extensions focus on what it *does*. I've really taken to
> that style, as I now almost never declare methods or computed properties in
> an initial type declaration, unless it's a very simple one; instead doing
> all my methods and protocol conformances in their own extensions.
>

The main problem I currently see with extensions: you can't conform to 
protocol in extension if you want to have stored properties to implement 
the protocol. And conforming to separate protocol in separate extension is 
a common practice and usually you need this in the same file when you 
define the type.
*This* was my main point when I suggest to allow stored properties *only in 
the same file where the type is declared*.

> i.e- I quite like that by the time you've finished your type declaration
> you have finalised what its size will be, and nothing else can change that,
> spreading it out feels like it could make that more confusing. It also IMO
> helps to encourage you to keep a type's contents fairly simple, as you can
> see in one place if you've made it very complicated.
>
> I suppose there's an argument for having the freedom to do it however you
> want, but I don't think spreading out across a module is a good idea;
> unless we're assuming that module in this context applies like in other
> proposals, where fileprivate is a "module" with only one file.

Personally, I don't suggest "spreading out across a module", just across 
the file where the type is declared. I agree that we should not allow this 
for across the module.

>
> I dunno, I just think that as a pattern the current requirement to keep
> stored properties within a type declaration enforces some good practices. I
> found it a bit jarring at first too, but after adapting to the type +
> extensions style I find I actually really like doing things that way.

Actually, *personally* I see no problems at all to have initially proposed 
'partial' syntax in addition to current extensions.

They can solve different problems, while at some situations you can be 
confused - both can be used to solve the same problem - i.e. you'll have a 
question, if you want 'extension' or 'partial' to just add utility method / 
conform to protocol(without stored properties) in *same* source.
*I'm* not afraid of this confusion, it will not be exposed abroad of the 
file, but I understand that such confusion is a show-stopper for proposal 
to be accepted.

But I do think that 'partial' should be allowed only in the same file(and 
later probably only in same submodule)

Moreover, actually I even prefer require a 'partial' modifier for base type 
declaration also, so even in the same file you can see that type will have 
additional blocks of declaration:

partial class MyType { // oh, there are additional parts of declarations in 
*this* file only.
   ...
}

partial MyType {
   ...
}

partial MyType : SomeProtocol {
   ...
}

Even more, I believe that there is an important difference exists between 
proposed 'partial' as method to split declaration of type(so, we should 
think about it as compiler will combine all the parts into one single 
definition) and between extension with allowed stored properties: access to 
scoped 'private' members. Consider this code:

partial class MyType {
	private var x = 10
	
	func someFunc() { print(boo) } // boo declared in partial
}

extension MyType {
	private var y = 20 // suppose stored properties are allowed
	func foo() {
		print(x) // can access 'x' in the *same* file?
	}
}

extension MyType {
	private var z = 30 // suppose stored properties are allowed
	func bar() {
		print(z+y) // can access 'y' in the same file ?
	}
}

partial MyType {
	private var boo = 100

	func baz() {
		print(x) // should 'partial' access 'x'?
			// (given partial allowed only in the same file)
	}
}

I believe extension should not access the scoped 'private' memeber of type 
or another extension, while partial declaration should be able to access as 
this is just the same definition of type like

partial class MyType {
	private var x = 10
	
	func someFunc() { print(boo) }

	private var boo = 100

	func baz() { print(x) }
}

So I want both: extensions and 'partial', But I understand that this can 
not be accepted because of "level of confusion"(tm)  and "cognitive 
load"(tm) 'partial' adds to the syntax.

So, at least, I'd like to have extensions with stored properties in the 
same file, even if 'scoped' members can't be exposed to them. It seems like 
this is a reasonable compromise between "best" and "nothing".