On Fri, 03 Dec 2010 19:06:36 -0500, Andrei Alexandrescu
<[email protected]> wrote:
On 12/3/10 5:17 PM, Steven Schveighoffer wrote:
On Thu, 02 Dec 2010 17:02:42 -0500, Michel Fortin
<[email protected]> wrote:
On 2010-12-02 16:14:58 -0500, "Steven Schveighoffer"
<[email protected]> said:
On Thu, 02 Dec 2010 07:09:27 -0500, Michel Fortin
<[email protected]> wrote:
My only concern with the "const(Object)ref" syntax is that we're
reusing 'ref' to denote an object reference with different
properties (rebindable, nullable) than what 'ref' currently stands
for. But it remains the best syntax I've seen so far.
Where it would be beneficial is in mimicking the tail-const
properties of arrays in generic ranges.
I have a container C, which defines a range over its elements R.
const(R) is not a usable range, because popFront cannot be const. So
now I need to define constR, which is identical to R, except the
front() function returns a const element.
So now, I need the same for immutable.
And now I need to triplicate all my functions which accept the
ranges, or return them.
And I can't use inout(R) as a return value for ranges.
If you can solve the general problem, and not just the class
tail-const, it would be hugely beneficial.
My thought was that a modifier on const itself could be stored in the
TypeInfo_Const as a boolean (tail or not), and the equivalent done in
dmd source itself.
I'm not sure I get the problem. Can you show me in code?
Here is an example range from dcollections (well, at least the pertinant
part), for a linked list:
[snip analysis]
@tail inout(Range) opSlice() inout
{
...
}
I was about to post a similar analysis, but my suggested conclusion is
very different: in my humble opinion, we must make-do without tail
const. We can't afford to inflict such complexity on our users.
BTW, even though I conceed that my ideas are too complex to be worth
using, I don't agree we must "make-do" without tail-const. We just need
to find a different way to solve the problem. Let's talk about how we
could add some sort of custom implicit casting to the type-system. And
actually, we need implicit lvalue casting (because all member functions
have ref this).
-Steve
