Denis Koroskin wrote:
> On Fri, 13 Feb 2009 17:24:54 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Rainer Deyke wrote:
>>> Andrei Alexandrescu wrote:
>>>> C++ ctors won't do the right thing if you use pointers, which is the
>>>> moral equivalent of using T[] inside MathematicalVector. If you refer to
>>>> std::vector instead, then that's a carefully-defined type that does have
>>>> the right copy constructor defined.
>>>  So where's the D equivalent of std::vector?  Phobos has nothing.
>>
>> It will.
>>
>>> I was under the impression that native arrays were intended to be used
>>> directly in D, something I rarely do in C++.  Certainly neither of the
>>> standard libraries has any hesitation about passing unadorned dynamic
>>> arrays around.
>>
>> Phobos2 plans to consistently consider T[] a range, not a full-fledged array. A range corresponds to a pair of iterators in STL.
>>
>>
>> Andrei
> 
> Will T[] get front, back, empty properties, and popFront(), popBack() methods?

Yes, not as methods, but as free functions.

> Perhaps, its the time T[] internal structure is changed!
> For example, ptr+size replaced by two pointers, some additional fields added etc..

I agree. Walter said let's get ranges going and then we can look into optimizing the structure. Ranges seem to work really well so the structural change will follow soon.


Andrei

Denis Koroskin wrote:
> On Fri, 13 Feb 2009 17:24:54 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Rainer Deyke wrote:
>>> Andrei Alexandrescu wrote:
>>>> C++ ctors won't do the right thing if you use pointers, which is the
>>>> moral equivalent of using T[] inside MathematicalVector. If you
>>>> refer to
>>>> std::vector instead, then that's a carefully-defined type that does
>>>> have
>>>> the right copy constructor defined.
>>> So where's the D equivalent of std::vector? Phobos has nothing.
>>
>> It will.
>>
>>> I was under the impression that native arrays were intended to be used
>>> directly in D, something I rarely do in C++. Certainly neither of the
>>> standard libraries has any hesitation about passing unadorned dynamic
>>> arrays around.
>>
>> Phobos2 plans to consistently consider T[] a range, not a full-fledged
>> array. A range corresponds to a pair of iterators in STL.
>>
>>
>> Andrei
>
> Will T[] get front, back, empty properties, and popFront(), popBack()
> methods?
> Perhaps, its the time T[] internal structure is changed!
> For example, ptr+size replaced by two pointers, some additional fields
> added etc..

once upon a time there was a huge discussion about template syntax.
one of the suggestions was:
A!(T) => A[t]

with such syntax we could use:
Array[T] - this would be an array with the added capacity field
Map[Key, Value] - instead of the current AA's
Set[T] - example of user defined template
...
Array[int] arr1; // dyn. array
Array[int, 3] arr2; static array with size 3

or maybe even better:
if n is constant => static array, otherwise dyn. with pre-set capacity
Array[int] arr3(n);

auto r = arr1[]; // range/slice of arr1

IMHO, it's not a good idea to have container types in the language. they should be provided by the stdlib and the language needs to provide only the syntax to make such types behave like builtins. D already provides operator overloads for that.

What is the result of the discussion?

Will the language change? Not once, could in 6-12 months?..

For me, the answer to that question was tantamount to answering the question "whether or not to use D for new projects?"


Weed пишет:
> (Has started here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81359)
> 
> To me still does not give rest performance of classes (in comparison
> with C++ or with D structs)
> 
> I still think that it is a serious problem.
> 
> Colleagues from our national D forum have asked to show it and I have written simple examples on D. I want to share with you too them.
> 
> On my computer the code with structure (i.e. object by value) runs in 6 times faster than a code with a class:
> 
> $ time ./struct
> 
> real    0m8.515s
> user    0m7.796s
> sys     0m0.016s
> $ time ./class
> 
> real    0m52.185s
> user    0m40.543s
> sys     0m0.076s

[...]

Weed Wrote:

> Will the language change?

Hmm... You already has Walter's answer. He's the boss.

Kagamin пишет:
> Weed Wrote:
> 
>> Will the language change?
> 
> Hmm... You already has Walter's answer. He's the boss.

I want a more specific answer (yes or no) if possible...

Weed wrote:
> Kagamin пишет:
>> Weed Wrote:
>>
>>> Will the language change?
>> Hmm... You already has Walter's answer. He's the boss.
> 
> I want a more specific answer (yes or no) if possible...

It will not. If you come up with some really awesome use case, then it could, but nobody has yet, and the issue comes up every few months.

Christopher Wright пишет:
> Weed wrote:
>> Kagamin пишет:
>>> Weed Wrote:
>>>
>>>> Will the language change?
>>> Hmm... You already has Walter's answer. He's the boss.
>>
>> I want a more specific answer (yes or no) if possible...
> 
> It will not. If you come up with some really awesome use case, then it could, but nobody has yet, and the issue comes up every few months.

Good (I think) use cases have been in this thread

Weed wrote:
> Christopher Wright пишет:
>> Weed wrote:
>>> Kagamin пишет:
>>>> Weed Wrote:
>>>>
>>>>> Will the language change?
>>>> Hmm... You already has Walter's answer. He's the boss.
>>> I want a more specific answer (yes or no) if possible...
>> It will not. If you come up with some really awesome use case, then it
>> could, but nobody has yet, and the issue comes up every few months.
> 
> Good (I think) use cases have been in this thread

They have not. The examples have been incomplete. You've provided use cases involving classes, but haven't given _any_ details about the contents of those classes.

It's possible that you have indeed found use cases, but you haven't actually shown them here.

Don пишет:
> Weed wrote:
>> Christopher Wright пишет:
>>> Weed wrote:
>>>> Kagamin пишет:
>>>>> Weed Wrote:
>>>>>
>>>>>> Will the language change?
>>>>> Hmm... You already has Walter's answer. He's the boss.
>>>> I want a more specific answer (yes or no) if possible...
>>> It will not. If you come up with some really awesome use case, then it could, but nobody has yet, and the issue comes up every few months.
>>
>> Good (I think) use cases have been in this thread
> 
> They have not. The examples have been incomplete. You've provided use cases involving classes, but haven't given _any_ details about the contents of those classes.
> 
> It's possible that you have indeed found use cases, but you haven't actually shown them here.

I do not understand the claims.

For example, any class that implements the mathematical object (matrix, vector, number, etc.) is suitable for example. I think it is obvious.

Yes, the discussion in this thread showed that almost always possible for each case to find a different approach, using additives and other scary code. But what if these "perversions" flaw somewhere in the idea of a "reference-only" type?

I understand people who are against the changes of language, as they would at least explore these changes. I myself belong to those people, I do not like changes associated with cosmetic amenities, breaking the old-established solution for years.

I also understand the people who came from the languages Java and C#, which is not familiar with the semantics of the class value.

But just such a case, when the inertia hinders the development of language and prevents them winning at least a substantial number of positions. (Namely: the replacement of old C++. Yes, I believe, without C++ replacement functionality D will not be needed.)

I think the problem is real and requires action. Not sure it will be a value semantic. Maybe we come up with something entirely new? I do not know.

But the problem is that one must at least acknowledge it and not come off the common phrases that "your use cases are not serious" etc.

Weed wrote:
> Don пишет:
>> Weed wrote:
>>> Christopher Wright пишет:
>>>> Weed wrote:
>>>>> Kagamin пишет:
>>>>>> Weed Wrote:
>>>>>>
>>>>>>> Will the language change?
>>>>>> Hmm... You already has Walter's answer. He's the boss.
>>>>> I want a more specific answer (yes or no) if possible...
>>>> It will not. If you come up with some really awesome use case, then it
>>>> could, but nobody has yet, and the issue comes up every few months.
>>> Good (I think) use cases have been in this thread
>> They have not. The examples have been incomplete. You've provided use
>> cases involving classes, but haven't given _any_ details about the
>> contents of those classes.
>>
>> It's possible that you have indeed found use cases, but you haven't
>> actually shown them here.
> 
> I do not understand the claims.
> 
> For example, any class that implements the mathematical object (matrix,
> vector, number, etc.) is suitable for example. I think it is obvious.

Absolutely not! Those cases involve no polymorphism! No virtual function calls.

> Yes, the discussion in this thread showed that almost always possible
> for each case to find a different approach, using additives and other
> scary code. But what if these "perversions" flaw somewhere in the idea
> of a "reference-only" type?
> 
> I understand people who are against the changes of language, as they
> would at least explore these changes. I myself belong to those people, I
> do not like changes associated with cosmetic amenities, breaking the
> old-established solution for years.

I don't think the resistance comes from intertia and committment to the "long-established solution". There's plenty of C++ programmers here (including myself).

> I also understand the people who came from the languages Java and C#,
> which is not familiar with the semantics of the class value.
> 
> But just such a case, when the inertia hinders the development of
> language and prevents them winning at least a substantial number of
> positions. (Namely: the replacement of old C++. Yes, I believe, without
> C++ replacement functionality D will not be needed.)

> I think the problem is real and requires action. Not sure it will be a
> value semantic. Maybe we come up with something entirely new? I do not know.
> 
> But the problem is that one must at least acknowledge it and not come
> off the common phrases that "your use cases are not serious" etc.

You really MUST start from a solid use case. I'm genuinely surprised that you've had so much trouble coming up with one; it suggests to me that you're not looking at the right problem.