On 4-dic-10, at 02:26, Steven Schveighoffer wrote:
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).
I fully agree with this.
I will try to recap what I think is the most clean solution from the
conceptual point of view, then maybe others have an idea on how to
find a good solution that is not too difficult to implement, and
doesn't break what was said in TDPL too much.
The current const implies that the references to that type have to be
constant.
tail const, and has the recursive definition I had given:
valueConst(T) is
T for basic types functions and templates
refConst(U)* if is(T U==U*)
refConst(U)[] if is(T U==U[])
V if is(T == struct), where V is a structure just like T, but where
each of its fields is tail const
tail const marks all that is copied when one assigns T v2=v1; as
mutable.
Indeed to protect v1 it is not needed to protect the values that get
copied in the assignment, those values can be changed without changing
v1.
For this reason tail const is the most weak const that one can have in
pure functions, in ideally should mean tail const (thus in some way
tail const comes from the protection of a starting const.
any lvalue by default should be tail const, if it was const, and tail
immutable if it was immutable, but is implicitly convertible to full
const/immutable.
in a way tail const is more fundamental as it is the least protection
that one has to give to protect some data owned by others.
If I have a global variable the current const/immutable can guarantee
that its value will not change, while tail immutable guarantees that
one can safely point to that data as it won't be changed: that data
can be shared safely (not necessarily by several threads, even simply
by several objects).
Thus both have their function, but in general I think that tail const
might be even more important (if I had to choose one const/immutable
type I would choose the tail one).
