www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - About typequalifier and generic containers.

reply "deadalnix" <deadalnix gmail.com> writes:
Once again a post DConf topic.

T[] implicitely cast to cont(T)[] . Isn't it nice ? Yes but, 
Foo!T do not with Foo!const(T), and for good reasons.

This make it very cumbersome to write collections in D in general 
and make them fully usable with the const system.

It has been raised several time by Steven and several others, I'm 
hitting the same problem as well.

Many people raised the need for better collection lib and I have 
to say I do agree. This and the allocator design are the 2 major 
pain point that need to be removed to get a high quality 
collection library.
May 05 2013
next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
On Sunday, 5 May 2013 at 16:32:37 UTC, deadalnix wrote:
 Foo!T do not with Foo!const(T), and for good reasons.

Can you give me an overview of those reasons, please?
May 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, May 05, 2013 18:34:44 =?UTF-8?B?Ikx1w61z?=.Marques 
<luismarques gmail.com> puremagic.com wrote:
 On Sunday, 5 May 2013 at 16:32:37 UTC, deadalnix wrote:
 Foo!T do not with Foo!const(T), and for good reasons.

Can you give me an overview of those reasons, please?

Foo!T and Foo!(const T) are completely different and essentially unrelated types. They're only connection is that they're instantiated from the same template. You can't assume that anything about them is the same. It's perfectly possible to do something like struct Foo(T) { static if(is(const(T) == T)) { string s; byte b; auto bar() { return s ~ b; } } else { T t; float baz() { return 2.2; } string toString() { "hello"; } } } So, the compiler can't assume that Foo!T has any relation to Foo!(const T). In reality, 99.999999% of the time, the only difference would be constness, but doing nonsense like what that Foo definition does is perfectly possible. With const T[] and const(T)[], the compiler knows all about how arrays work, so it knows that converting const T[] to const(T)[] (i.e. make it tail-const) is perfectly valid, and it just can't do that with user-defined types. At one point, I tried to make a range's opSlice return a tail-const version of the range (and alias that to this for implicit conversions), but I ended up with a recursive template instantiation in the process, which blew the stack when compiling or somesuch. I _think_ that it could be done by using static if to break the recursion (though I didn't try that at the time), but I'm not entirely sure that that can be done, and even if it can, then it's getting fairly complicated to define a range which can be sliced as tail-const like arrays can, which likely means that almost no one will do it. I don't know what the solution is (Steven has some ideas, but I don't know what they are), but if const and ranges are ever going to mix, we need to be able to reasonably get tail-const ranges from const ranges. Otherwise, as soon as you get a const range, it's pretty much useless. - Jonathan M Davis
May 05 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 05 May 2013 23:32:47 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 I don't know what the solution is (Steven has some ideas, but I don't  
 know
 what they are), but if const and ranges are ever going to mix, we need  
 to be
 able to reasonably get tail-const ranges from const ranges. Otherwise,  
 as soon
 as you get a const range, it's pretty much useless.

I wrote a proof-of-concept tail-const range framework at some point, and posted it to BugZilla[1]. It shows that such a thing is possible in the language as-is, however I don't think it would win a beauty contest. This is a hard problem to get right, and I'd love to see Steven's ideas. [1]: http://d.puremagic.com/issues/show_bug.cgi?id=5377 -- Simen
May 05 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 05 May 2013 15:46:17 -0700, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Sun, 05 May 2013 23:32:47 +0200, Jonathan M Davis  
 <jmdavisProg gmx.com> wrote:

 I don't know what the solution is (Steven has some ideas, but I don't  
 know
 what they are), but if const and ranges are ever going to mix, we need  
 to be
 able to reasonably get tail-const ranges from const ranges. Otherwise,  
 as soon
 as you get a const range, it's pretty much useless.

I wrote a proof-of-concept tail-const range framework at some point, and posted it to BugZilla[1]. It shows that such a thing is possible in the language as-is, however I don't think it would win a beauty contest. This is a hard problem to get right, and I'd love to see Steven's ideas. [1]: http://d.puremagic.com/issues/show_bug.cgi?id=5377

Stay tuned. My ideas are evolving (article in progress). I think it will not necessarily be an easy pill to swallow. I want to get all my thoughts ironed out before posting. But the gist of it is: 1. Yes, it is a big problem, and it's increasingly apparent that it needs to be solved. 2. It cannot be done via library. We will necessarily need compiler/language help for this. 3. It will not be that disruptive, simply because nothing can do it properly now. So I think the change will give a large ROI (that was for Don). -Steve
May 06 2013