[swift-evolution] Pitch: Partial Implementations

[Haravikk]

> On 24 Mar 2017, at 12:13, Vladimir.S <svabox at gmail.com> wrote:
>> On 24.03.2017 12:50, Haravikk wrote:
>> 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*.

Even, so I think this is kind of the right way to do it; protocols don't specify stored properties, only a name and type, so IMO it doesn't necessarily follow that fulfilling that requirement with a store property belongs in an extension.

Consider for example a conformance to Indexable, I want to do this in an extension and I need to decide to how I'm going to handle the startIndex and endIndex properties. For some reason I decide I'll store one in my type and compute the other:

	struct MyCollection<E> {
		let startIndex:Int = 0
	}

	extension MyCollection : Indexable {
		var lastIndex:Int { return someValue() } // it's a really bad collection
	}

Bit contrived I know, but here I've been forced to think about where to put each, hopefully making it more obvious that my choice for startIndex was a waste of space, since it has made MyCollection 4/8 bytes larger.

I just really like that property of the pattern; it also means that, if I keep the type declaration clean, then at a glance I can see what contributes to the type's actual contents and size. Here someone new to the code would immediately see that I was an idiot 😉

I'll agree that there's some separation from the protocol that it was actually required by, but I prefer it that way to having stored properties scattered around, even within the same file (especially since we're often talking about very large files here for complex types). This "feature" is good for someone new to the code as it makes it easy to learn what is a stored vs computed property, especially if it has encouraged the developer to keep the number of stored properties to a minimum.

I dunno, maybe it comes from having once had header files for everything, but I like this separation of concrete components of a type.


There was a proposal a while ago as an alternative to stored properties in regular extensions, which was the use of "mix-ins", which would be its own category. The aim of those is to modularly build up a type and quickly add conformances from reusable mix-ins, but you could also do it just for a single type.

I preferred that idea because it formalises that this is something you can't just do to an imported type, and gets away from this idea of having something you can do with an extension, but only at the file-scope, which I feel kind of weird about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/717889a2/attachment.html>