[swift-users] It seems like we really need an #include preprocessor directive?

[Edward Connell]

Putting a struct with your common vars in it seems like it wouldn't work,
because now it is a member and the vars aren't exposed on your object
directly, so the outer struct wouldn't conform to the protocols.

My original problem with inheritance is that you can't correctly adopt a
protocol on a base class because protocol extensions that specialize based
on Self will use the Self of the base, not of the final class.

Inheritance is fine if nothing happens in the base classes except declaring
the vars required by the protocol. However, any protocol extension
functionality picked up might be the wrong code for the final class. The
only way I see for it to come out right is that the protocols have to be
adopted only by the final class/struct.

#include was just a first thought of how to deal with the need to duplicate
the protocol var declarations. I agree, it's not a good way to handle the
problem.

Maybe I misunderstood it's purpose, but it seems the swift team is using
GYB/python to do code generation to deal with code duplication to address
this problem. That seems even messier to me.


On Sat, Mar 11, 2017 at 10:29 PM, Jens Alfke <jens at mooseyard.com> wrote:

>
> On Mar 11, 2017, at 10:21 PM, David Sweeris <davesweeris at mac.com> wrote:
>
> (I see absolutely nothing wrong with inheritance, and it solves exactly
> this sort of problem. Yes, structs can’t inherit, but they can contain a
> common struct as a member, which is quite similar and addresses this issue.)
>
>
> That forces you into reference semantics, though.
>
>
> No it doesn’t. A struct member of a struct is still a value. If you put a
> common *class* instance in a struct, that would be reference semantics.
>
> —Jens
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170311/4a779d6c/attachment.html>