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
parent reply =?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
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 parent reply "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
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