> Protocols currently require you to redeclare their properties, but we could
> add a feature to change that if there was a strong enough justification.
Sometimes, this would be very handy (not only for structs) — but I'd expect
that there are at least as many cases where you don't want that
> On Aug 2, 2016, at 8:44 PM, Tino Heth via swift-users
> wrote:
>
> * yes, an embedded "address"-struct would be an alternative — but copy &
> paste or writing everything in assembler is an alternative as well ;-)
The other alternative for this particular case is a
> I thought the problem with struct polymorphism (specifically the stack size
> issue) *was* the fundamental reason we can’t have “substructs”.
As I said:
I guess this is the reason we don't have "substructs" now — but inheritance can
be useful without polymorphism:
Imagine an application that
> On Aug 1, 2016, at 5:28 PM, Rick Mann via swift-users
> wrote:
>
> It sure seems natural.
>
> Is there some reason the language can't allow a sub-struct to add member
> variables, such that the whole is treated like a contiguous set of members?
Class-style
> On Aug 2, 2016, at 4:03 AM, Tino Heth via swift-users
> wrote:
>
> There is no fundamental reason to disallow struct inheritance, and I started
> a pitch where afair one member of core agreed it would be useful — I hope
> there is time to add it in the next year.
>
> * Structs have statically-dispatched methods and properties; there's no
> ability to override.
>
I wonder if that is an inherent property of structs, or a side-effect from them
having no inheritance. There is no way to define something else which also “is”
a CGRect, so all structs are
There is no fundamental reason to disallow struct inheritance, and I started a
pitch where afair one member of core agreed it would be useful — I hope there
is time to add it in the next year.
There is, however, a fundamental problem with struct polymorphism:
As soon as you add members, you
> On Aug 1, 2016, at 5:28 PM, Rick Mann via swift-users
> wrote:
>
> It sure seems natural.
>
> Is there some reason the language can't allow a sub-struct to add member
> variables, such that the whole is treated like a contiguous set of members?
Structs are very
> On Aug 1, 2016, at 8:28 PM, Rick Mann via swift-users
> wrote:
>
> It sure seems natural.
>
> Is there some reason the language can't allow a sub-struct to add member
> variables, such that the whole is treated like a contiguous set of members?
>
> In my case, I
It sure seems natural.
Is there some reason the language can't allow a sub-struct to add member
variables, such that the whole is treated like a contiguous set of members?
In my case, I have a rect-like value type, but I'd rather it inherit from
CGRect, rather than contain a CGRect. That makes
10 matches
Mail list logo