On 03/26/2016 02:01 PM, Walter Bright wrote: > On 3/26/2016 1:03 AM, Dicebot wrote: >> On Saturday, 26 March 2016 at 07:42:43 UTC, Jonathan M Davis wrote: >>> So, while the separation between structs and classes definitely good >>> for D >>> code in general >> >> I disagree with this statement. The very presence of utils like >> `Rebindable` or >> `scoped` indicates this wasn't a very clean design choice, not in a >> way it was >> implemented at least. > > I've worked a lot with C++ aggregates that were confused about whether > they were a floor wax or a dessert topping, and talking to their > implementors showed they had little idea of the consequences (and bugs) > of those choices. > > D's design has debatable flaws, but I'm confident they are much > diminished over the flaws and traps in the C++ design.
It is hard to argue that but I have never encountered any issues from actual confusion between struct and class in C++ (because there isn't any real difference), only from misusage of virtual types. >> what I would consider convenient is to limit struct/class distinction > to polymorphism exclusively, with not extra implications. So that you > can still can do `MyClass on_stack;` (any `MyClass` is treated as type > of object) but passing it to function wouldn't compile unless `ref` is > also used. > > So where it is allocated you'd have 'MyClass' and everywhere it is used > you'd have 'ref MyClass'. There are a lot of consequences of this, such as: > > 1. Want to switch between a class and a struct? You've got lots of > editing to do. I'd prefer to do lot of editing as opposed to lot of reading through to not introduce silent semantical bugs - which is exactly how switching between struct and class looks now. This is a major benefit, not an issue. > 2. You'd have to invent a way to do 'alias ref MyClass T;' No way. `typedef int* p_int_t` is one of worst popular C idioms in my opinion. Typing extra three letters is a very minor price for having a code which looks like what it does. > 3. ref has special semantics in D about being a non-escaping pointer. > This means issues if you want a 'ref MyClass' field in a struct. MyClass* should also be applicable, I have only mentioned `ref` because non-escpaing is usually desired :) Btw implementation of DIP25 is heavily incomplete, I have never managed to make it work in any of practical attempts. There are quite some bug reports open : https://issues.dlang.org/buglist.cgi?quicksearch=dip25&list_id=207387 > I'm not saying your idea is necessarily bad, but there is a heckuva lot > to think about in interactions with other features. It's not so easy to > produce a design that doesn't have a nail sticking up here or there. I > don't know of any language that succeeded in that. Well, languages that simply declare everything a reference (JS) or dropped support for inheritance based polymorphism (Go, Rust) are much more consistent in that regard in my opinion :) There isn't much point in discussin details at this point as the ship has long sailed. But I definitely consider this one of underdesigned parts of D language.
