new principle of division between structures and classes

[Weed]

Bill Baxter пишет:
> 2009/1/11 Weed <resume755 at mail.ru>:
>> Bill Baxter пишет:
>>
>>> But since classes can be polymorphic, value copying gets you into
>>> slicing problems.  That's why value copying is disabled to begin with.
>>>  So disabling value copies is a good thing.
>> It is not always a good thing.
> 
> Yeh, I just mean there is some merit in disabling value copies.  But I
> don't rule out the possibility that there may be an even better way
> that banning them altogether.
> 
>> I propose to prohibit only the copying by value of the base type to
>> derivative type
> 
> Ok, this is key.  How do you propose to do this?  In general it
> requires a runtime check, I think.
> And I think you need to say that you prohibit copying unless
> typeA==typeB exactly.  If you allow copying either way between base
> and derived you are asking for trouble.
> 
> But still given
>   Base x = get_one();
>   Base y = get_another();
>   *x = *y; // presumed value copy syntax
> 
> you have no way in general to know that x and y are really both a Base
> at compile time.  So you must have a run-time check there.  Perhaps it
> could be omitted for -release builds, though.

It can lead to a difficult and non-reproduceable errors than old
C++-style splitting.

It is possible to try to prohibit assignment of the dereferenced
pointers? Simply to prohibit assignment too it is possible, essentially
it changes nothing.

>>> And that's also the problem with putting scope'd things inside another
>>> class or an array.  Since they don't have value semantics,
>> Yes, this is what I mean
> 
> So assuming you had this, the important question is what would you do with it?

The most difficult. My arguments:

1. Problem of a choice of correct type for the object. A mathematical
matrix - a classical example. A class it should be or structure?

My offer without serious consequences allows to move solution of this
problem from a design stage to a programming stage - is it will be
simple by replacement keyword class to struct.


2. Performance increases. It is not necessary to allocate at the
slightest pretext memory in a heap.


3. I offer syntax which presumably does not break an existing code.
+ On how many I understand, in the existing compiler all necessary for
implementation already is, a problem only in syntax addition.


4. Java and C# also uses objects by reference? But both these of
language are interpreted. I assume that the interpreter generally with
identical speed allocates memory in a heap and in a stack, therefore
authors of these languages and used reference model.

D is compiled language and to borrow reference model incorrectly. In D
the programmer should have possibility most to decide where to place object.


> You still have the problem that the current system works pretty well.
> And has a lot of history.  So you need a very compelling use case to
> convince Walter that something should change.

Thus, actually Java and C# systems works pretty well. And they has a lot
of history. But not D.


This situation reminds me history with the Hungarian notation:
Many years ago many developers have started to deliver interfaces and to
sell books where it was used. This very correct invention affirmed as
many books that and only in ~5 years there were articles with the
materials specifying in groundlessness of usage of this notation. Till
this time many entered it into corporate standards and suffered, though,
I am sure, they were visited by thoughts about irrelevance of the
given notation except for special cases.