<div><div dir="auto">There's been talk about "protocol forwarding" that I think would achieve a lot of these goals, without the sharp edges involved trying to define inheritance between a class and a struct. The proposed feature would eliminate the boilerplate you're talking about.</div><div dir="auto"><br></div><div dir="auto">I'm on my phone so I can't pull up links to old discussions, but Matthew Johnson is who was pushing it so you may want to look back at what he's said on the topic.</div><div dir="auto"><br></div><br></div><div><div class="gmail_quote"><div>On Thu, Jun 22, 2017 at 2:28 PM Mike Kluev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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"><div><div>On Wed, 21 Jun 2017 15:04:46 David Moore <mooredev at <a href="http://me.com" target="_blank">me.com</a>> wrote:</div><div><br></div><div>> This would be a bit counter-intutivie in my opinion, and it’s already possible </div><div>> with the language today. First of all, structs in Swift cannot be built upon. </div><div>> Rather, I believe the intention is to use protocols for such a task. That’s what </div><div>> the new Swift String and Substring structs do. The following code example </div><div>> demonstrates the intended behavior, without any additional language improvements.</div><div>> </div><div>> protocol Foo {</div><div>> func a() -> Any?</div><div>> }</div><div>> </div><div>> extension Foo {</div><div>> func a() -> Any? {</div><div>> return nil</div><div>> }</div><div>> }</div><div>> </div><div>> struct ValueSemantics: Foo {}</div><div>> </div><div>> class ReferenceSemantics: Foo {}</div><div class="gmail_extra"><br></div></div><div><div class="gmail_extra">while you can use protocols, and protocol extensions specifically, to share implementation there are two obvious problems with this "workaround":</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) protocol extensions' based implementation is very limited as you have no storage around. e.g. start with a normal struct method that accesses an instant variable and try to refactor it into a protocol extension... in other words try doing anything useful other than "return nil" above, anything that requires instance variable access. you'll have to be creative in your protocol implementation, e.g. have a "var storage { get set }" as part of the protocol and implement that "var storage" inside your struct (and class), and in case of "struct" it would be strange as the struct itself is (already) the storage, so you would introduce another level of indirection for no good reason other than to satisfy this workaround, which is not nice to begin with and has to be thought upfront (see below)</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) the proposed method works with value types that are already available (e.g. the OS structs or third party ones) - something you can not change but still want to wrap into a reference type.</div><div class="gmail_extra"><br></div><div class="gmail_extra">this proposal is purely a syntactic sugar if you will... imagine a value type "S" that you didn't create that has two hundred methods in it. of course you can:</div><div class="gmail_extra"><br></div><div class="gmail_extra">class C /* : S */ {</div><div class="gmail_extra"><br></div><div class="gmail_extra">// implement manually:</div><div class="gmail_extra"> var `struct`: S</div><div class="gmail_extra"><br></div><div class="gmail_extra"> // manually put two hundred pass through methods here...</div><div class="gmail_extra"><br></div><div class="gmail_extra"> func method1() {</div><div class="gmail_extra"> `struct`.method1()</div><div class="gmail_extra"> }</div><div class="gmail_extra"> // ...</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">it would be just painful. but the semantic of the proposed solution is exactly the same, so any question "how it will do this" or "how it will behave in regards to that" can be immediately answered by looking at the equivalent "manual" implementation, so no hidden surprises here.</div></div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Mike</div><div class="gmail_extra"><br></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>