<div dir="ltr"><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important">Perhaps some types don’t lend themselves to being extended?</p>
<p style="margin:0px 0px 1.2em!important">Intuitively I would think any extensions should not affect the core behaviour at all. So if I extended a type by adding a property <code style="font-size:1em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">x</code>, two instances with everything else the same and different values of <code style="font-size:1em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">x</code> should still be considered equal by a type-specific equality check. For example you would agree that <code style="font-size:1em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">1 + 1 = 2</code> but what if the numbers were coloured red, blue, and yellow respectively, like fridge-magnets, should <code style="font-size:1em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">1(red) + 1(blue) = 2(yellow)</code>? I think yes. The colour is an extension, it doesn’t change the fundamental concept or behaviour of an integer number.</p>
<p style="margin:0px 0px 1.2em!important">I see extensions as a way to add functionality (and potentially data), but without affecting the core behaviour. If you wanted to change behaviour then you should use inheritance or composition to create something new. You can’t then use your own type for instances created by a library, unless it gives you a way to do that, the library would expect its own types to behave in a predictable way, similarly they should behave the same way when extended.</p>
<div title="MDH:PGRpdj5QZXJoYXBzIHNvbWUgdHlwZXMgZG9uJ3QgbGVuZCB0aGVtc2VsdmVzIHRvIGJlaW5nIGV4
dGVuZGVkPzxicj48YnI+SW50dWl0aXZlbHkgSSB3b3VsZCB0aGluayBhbnkgZXh0ZW5zaW9ucyBz
aG91bGQgbm90IGFmZmVjdCB0aGUgY29yZSBiZWhhdmlvdXIgYXQgYWxsLiBTbyBpZiBJIGV4dGVu
ZGVkIGEgdHlwZSBieSBhZGRpbmcgYSBwcm9wZXJ0eSBgeGAsIHR3byBpbnN0YW5jZXMgd2l0aCBl
dmVyeXRoaW5nIGVsc2UgdGhlIHNhbWUgYW5kIGRpZmZlcmVudCB2YWx1ZXMgb2YgYHhgIHNob3Vs
ZCBzdGlsbCBiZSBjb25zaWRlcmVkIGVxdWFsIGJ5IGEgdHlwZS1zcGVjaWZpYyBlcXVhbGl0eSBj
aGVjay4gRm9yIGV4YW1wbGUgeW91IHdvdWxkIGFncmVlIHRoYXQgYDEgKyAxID0gMmAgYnV0IHdo
YXQgaWYgdGhlIG51bWJlcnMgd2VyZSBjb2xvdXJlZCByZWQsIGJsdWUsIGFuZCB5ZWxsb3cgcmVz
cGVjdGl2ZWx5LCBsaWtlIGZyaWRnZS1tYWduZXRzLCBzaG91bGQgYDEocmVkKSArIDEoYmx1ZSkg
PSAyKHllbGxvdylgPyBJIHRoaW5rIHllcy4gVGhlIGNvbG91ciBpcyBhbiBleHRlbnNpb24sIGl0
IGRvZXNuJ3QgY2hhbmdlIHRoZSBmdW5kYW1lbnRhbCBjb25jZXB0IG9yIGJlaGF2aW91ciBvZiBh
biBpbnRlZ2VyIG51bWJlci48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+SSBzZWUgZXh0ZW5zaW9u
cyBhcyBhIHdheSB0byBhZGQgZnVuY3Rpb25hbGl0eSAoYW5kIHBvdGVudGlhbGx5IGRhdGEpLCBi
dXQgd2l0aG91dCBhZmZlY3RpbmcgdGhlIGNvcmUgYmVoYXZpb3VyLiBJZiB5b3Ugd2FudGVkIHRv
IGNoYW5nZSBiZWhhdmlvdXIgdGhlbiB5b3Ugc2hvdWxkIHVzZSBpbmhlcml0YW5jZSBvciBjb21w
b3NpdGlvbiB0byBjcmVhdGUgc29tZXRoaW5nIG5ldy4gWW91IGNhbid0IHRoZW4gdXNlIHlvdXIg
b3duIHR5cGUgZm9yIGluc3RhbmNlcyBjcmVhdGVkIGJ5IGEgbGlicmFyeSwgdW5sZXNzIGl0IGdp
dmVzIHlvdSBhIHdheSB0byBkbyB0aGF0LCB0aGUgbGlicmFyeSB3b3VsZCBleHBlY3QgaXRzIG93
biB0eXBlcyB0byBiZWhhdmUgaW4gYSBwcmVkaWN0YWJsZSB3YXksIHNpbWlsYXJseSB0aGV5IHNo
b3VsZCBiZWhhdmUgdGhlIHNhbWUgd2F5IHdoZW4gZXh0ZW5kZWQuPGJyPjxicj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 3 Nov 2016 at 15:14 Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Has anybody thought about the semantic issues of out-of-module extensions with stored properties apart from the implementation issues?<br class="gmail_msg">
<br class="gmail_msg">
Such properties could potentially wreak havoc with the semantics of the type being extended. How would these properties play nice with an existing definition of equality, for example? How can it be guaranteed that their value is consistent with the remaining state? And kept that way in case of mutability?<br class="gmail_msg">
<br class="gmail_msg">
-Thorsten<br class="gmail_msg">
<br class="gmail_msg">
> Am 15.10.2016 um 03:01 schrieb Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Let extensions introduce stored properties, but only in the same module as the type’s definition. Then, the compiler can just take any extensions into consideration when it’s determining the size of the type, just as if the properties had been declared in the type. Declaring stored properties on an extension outside of the type’s module results in a compiler error, exactly as today. This would, without any performance drawbacks, solve one of the big problems that people are hoping to solve via stored properties in extensions—the ability to organize members by protocol conformance.<br class="gmail_msg">
><br class="gmail_msg">
> Yes please! A big strong +1 to this from me. I can think of several specific chunks of problem code that this would clean up immensely.<br class="gmail_msg">
><br class="gmail_msg">
> Contra Karl in another message, it’s _in-module_ stored property extensions that I want most frequently. By far.<br class="gmail_msg">
><br class="gmail_msg">
> It seems to me that Charles’s idea could be introduced as its own proposal. If out-of-module stored property extensions do eventually become feasible, then Charles’s proposal is a good stepping stone. If they never do, then his proposal has done no harm.<br class="gmail_msg">
><br class="gmail_msg">
> I realize this probably falls into the post-ABI stability bucket, but I’d love to help write/support the proposal when its time comes.<br class="gmail_msg">
><br class="gmail_msg">
> Cheers,<br class="gmail_msg">
><br class="gmail_msg">
> Paul<br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-evolution mailing list<br class="gmail_msg">
> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>