Why is separating class ind struct is bad?

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Tue Mar 29 00:51:59 PDT 2016


On 3/28/2016 9:56 PM, Dicebot wrote:
> 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.

Misusage of virtual types is the confusion.


>> 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.

My experience is the opposite. I've found it quick & easy to attempt different 
data structures in D because of the minimal editing. In C++, I (and I suspect 
most people) just go with their first design because it is too much of a pain to 
edit all the usages.

That is what I've dubbed "brittleness". One way I was able to quickly achieve 
speed in Warp was it was easy to try out different data structures. Much, much 
easier than in C++. The end result could be done in C++, but getting there would 
probably not have happened.


>> 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.

You'd have to give up on writing generic code, then.


> 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 :)

JS and Go throw a lot of capability under the bus in order to achieve 
consistency. It's a high price. I don't know enough about Rust to say what their 
tradeoffs here really are.


> 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.

True dat.



More information about the Digitalmars-d mailing list