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.
The burden of defining @tail const/immutable/inout functions in addition
to n...@tail const/immutable/inout functions (sometimes the distinction
would need to be made!) is just too high. I think we need to work out
solutions within the existing language.
I had not thought of it this way. I assumed you would only need to define
a function as tail-const or const. Certainly if a function can be const,
you don't need a tail-const version also do you? A ref to tail-const
should implicitly cast to ref to const. If you need tail-const version,
then a const object should not be able to call this.
Immutable is different, ref to tail-immutable does not implicitly cast to
ref immutable. This really is a shame, I think you are right, we cannot
do tail-const generically in this way :( I overlooked this because arrays
are passed to their 'member' functions generally by value and not by
reference. The same is not true for structs with member functions.
But we absolutely need a way to say "this is implicitly castable to it's
tail-const version." This is the problem I showed at the end of my
earlier post -- you cannot implicitly convert Range into ConstRange. It
would be nice to have an enforceable way to allow this, so that the burden
of proof that implicit casting works properly is not on the developer.
In addition, the way inout works would be nice to hook into this
mechanism, so you could describe how inout applies to a tail-inout version.
Thanks for pointing this out.
-Steve
