== Quote from zoli ([email protected])'s article > Andrei Alexandrescu Wrote: > > Today, structs can't write their own this(). There aren't very solid > > reasons for that except that it makes language implementation more > > difficult. > > > If the new "operator" for the class is redesigned to have multiply allocation > types > (allocate on heap, allocate on stack, etc.?), there is no main drawback of > using classes instead of structs for small objects( like vec2, vec3) as well.
Yes there is. How about the cost of storing vtbl and monitor? Actually, just last night I was in a corner case where this mattered (as well as needing fine control over allocation), so I ended up rolling my own polymorphism with structs. This is not a complaint about the design of D classes. They do exactly what they should do: Handle the first 99% of use cases well and make people in obscure corner cases roll their own from lower level primitives rather than succumbing to the inner platform effect. However, I think it would be ridiculous not to allow simple syntactic sugar like non-polymorphic member functions on structs. > I don't think if there's any reason to use struct with member functions from that point, use class instead. And hence struct can be the good old plain data structures again, to give some semantics to a block of memory. Ok, simple example that's not a corner case: How about storing one inline in an array?
