Bill Baxter пишет: > 2009/1/11 Weed <resume...@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 assured, they were visited by thoughts about irrelevance of the given notation except for special cases.