Poll: a nonstate keyword

[Fawzi Mohamed]

On 2008-05-31 18:41:24 +0200, "Janice Caron" <caron800 at googlemail.com> said:

> On 31/05/2008, Fawzi Mohamed <fmohamed at mac.com> wrote:
>> It seems that with a safe no_state and a cast this is possible, so yes I
>> very much want no_state.
> 
> But it's likely also to be possible /without/ nostate.
> 
> As I noted in my first post on this thread, only a small handful of
> use-cases for nostate (aka mutable, aka unpaintable, etc) have been
> identified. One of these uses is caching (aka memoization). The
> current plan is to make caching available as a library solution, and
> so *therefore*, you will not need "nostate" in order to do this.
> 
> I have no idea whether or not the library solution will be considered
> pure. I imagine that if it can be proven safe, then it will count as
> pure. If not, well, there's always explicit casting.
> 
> So, given that, do you /still/ want nostate? Remember that (like
> explicit casts and unions) it opens the door to /serious/ abuse of the
> const system, just like in C++. Inexperienced programmers may well
> think to themselves: "I can't get this program to compile, unless I
> make member x mutable, so I'll do that". It seems to me that instead
> of opening that door, a better solution is (1) identify all reasonable
> use-cases (and we've only managed to come up with three or four so
> far, so even if we've missed a few, it's clearly not a big number),
> and then (2) provide alternative solutions for each of those
> use-cases.
> 
> What do you think?

Yes, I agree that the no_state can be dangerous (and in fact it is the 
primary reason I was dubious about it).
If the library solution is efficient then and the use cases I 
identified are covered then I see no need for the keyword (and keeping 
the language simple and ensuring the the users understand the style of 
the language is worth some effort).
What made me change a little my idea is that writing down the use cases 
I saw that most of them can be implemented efficiently (both in space 
and time) with mutable state.
If the compiler really gets more aggressive in ensuring that invariant 
is constant then the only possible solution will be fully external 
(id_number in the object+cleanup handle in destructor, and external 
hashtable mutable_state[id_number]), and it would be a pity to have to 
pay this extra cost when most cases in which this is used are related 
to the need of being more efficient.
Still maybe it is a price that does not have to be payed (if the 
library solution can avoid it) or is worth being payed.

Fawzi