On 11/30/10 12:38 PM, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 13:24:37 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 11/30/10 12:13 PM, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 10:36:53 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
I agree that the problem is difficult but disagree with the angle.
This is not the challenge, and it is not only mine to take. To the
extent we're interested in making D a successful language, we're all
on the same boat, so the challenge belongs to us all.
Adding a new type constructor to the language or generally a new
feature is always possible, but has a high cost. Half of the community
throws their hand in the air with each new feature, and the other half
throws them in the air for each feature that could have been. The key
is to navigate such that as many good designs are expressible as
easily as possible.
The real challenge is to solve the problem within the global set of
constraints we have, not to prove that a language feature would solve
it. I know a language feature would take care of the issue, the same
way money would take care of buying a nice house. The challenge is to
have a nice house when money _is_ limited.
IMO opinion, the cost of modifying the language so that a library
solution that half-solves the problem is possible, in order to create a
template that handles all sorts of odd cases is far greater than a new
keyword that would also enable things like tail-const ranges.
I'm not at all convinced. The general issue at stake is creating smart
references. Any inroads into solving that enables entire new classes
of designs. You're saying, forget smart references, let's create a
special smart reference.
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.
When we defined the const system, we had some goals: guaranteed
immutability, simple unification of functional and procedural, economy
of means. We were well aware of the tail const issue, and we made the
executive decision that we will punt on it on account of it being
relatively rare in practice, and partially addressable with Rebindable.
As of this time I don't know whether that is true or not.
Now say we define @tail const or whatever. That serves a case of
questionable frequency with an in-language solution that affects anyone
learning the language. This is a huge deal. I don't understand your not
understanding.
So please let's look into what the limitations of library-based
solutions are. We shouldn't be triumphantly proclaiming that Rebindable
is insufficient or inadequate. We should be looking into ways of making
it and other library solutions work, and understand that relying on an
in-language solution would be defeat, not victory. Every problem that
makes Rebindable not work also invalidates other useful designs.
Conversely, relying on a narrow language change that builds Rebindable
into the language definition would address the occasional tail-const
situation but will miss the train on many other, larger, issues.
Same discussion goes about non-nullable. We don't need the compiler to
understand non-nullable types, we need to imbue the compiler with the
ability to enforce arbitrary user-defined state invariants, non-null
being one of them.
To go with your analogy, we own the bank (compiler), we can print our
own money...
And we all know where that takes.
Better compiler? Better smart references? Yep, I agree :)
I meant bankruptcy.
Andrei
