On 30-nov-10, at 22:24, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 15:47:22 -0500, Andrei Alexandrescu <seewebsiteforem...@erdani.org
> wrote:
On 11/30/10 12:38 PM, Steven Schveighoffer wrote:
No, that's not what I'm saying. Creating a language-based tail-const
solution *unifies* all references, including any smart references
you
can create. I can say tail-const anything and it always means the
same
thing. It's another tool to allow creating of smart references.
Without
this, we have to special case tail-const in all smart reference
types.
If anything Rebindable is a special case smart reference, it only
addresses class tail-const. The language solution addresses general
tail-const. E.g. how does Rebindable address tail-const ranges?
I see it 100% opposite from what you are saying, a library solution
looks to me like "look! we don't have to change the language to add
language features, all you need is this template that adds 10k of
bloat
to your exe! And why do you need to pass them as parameters, just
create
a new local variable? And why do you need it to work with *all*
reference types, there's other syntax for that!" All for the sake
of not
changing the language, which I think is the more direct and complete
solution. I don't really understand the resistance.
Understanding the "resistance" is very simple. Right now a lot of
current readers cheerily ignore this thread. Also a lot of
potential users couldn't care any less. Once the feature will be in
the language, it will affect them all.
It affects them all as much as Rebindable affects them all. Either
way, it's something new they have to learn, whether it's a language
feature or a library feature. This argument makes no sense.
Another way to look at it -- whichever solution is used is really
going to affect only library writers, not library users. Whether
the user writes:
@tail const(C);
or
Rebindable!(const(C))
or something else is really irrelevant to them, what's relevant is
what hoops do I as a library writer have to jump through to get this
damned thing to work seamlessly.
I mostly agree with Steve (I just made it though the thread), I also
find tail const very useful.
In fact I independently wrote a related post about tail const (but
with a different syntax).
The fact that tail const can be reasonably extended to any type, and
still guarantees purity shows its usefulness.
mostly it can be seen as a shortcut to declare a special kind of
constness, only for classes one can express something with tail const
that cannot be directly expressed with const()
