The Status of Const

Graham St Jack Graham.StJack at internode.on.net
Thu Aug 12 21:16:19 PDT 2010


On 13/08/10 12:16, Jonathan M Davis wrote:
> On Thursday 12 August 2010 19:09:51 Michel Fortin wrote:
>    
>> On 2010-08-12 18:56:50 -0400, dsimcha<dsimcha at yahoo.com>  said:
>>      
>>> How can these limitations be worked around and/or fixed?
>>>        
>> Unsatisfaction about Rebindable seems pretty generalized.
>>
>> Here's an idea for a solution. Basically the problem is only in the
>> syntax, where the reference is implicitly part of the object's type and
>> thus impossible to put outside from the type modifier. An easy solution
>> would be to add an explicit reference marker, but this would change the
>> syntax for existing code, and I have to admit the current syntax is
>> nice (up until you try to add a modifier). But we could make the
>> reference marker optional, like this:
>>
>> 	Object o; // implicitly a reference
>> 	Object ref o; // explicit reference marker
>>
>> Both would be allowed and equivalent. While the first form is nicer to
>> the eye, the second makes it easy to apply a type modifier while
>> excluding the reference:
>>
>> 	const(Object)ref o;
>> 	shared(Object)ref o;
>>      
> Now, _that_ seems like a good idea. It doesn't even require a new keyword. It's
> also quite clear and understandable. It would be a big improvement I think.
> There may be downsides of some kind, but I can't think of any. Unless someone
> can come up with a reason _not_ to do this, it seems to me like it's a really
> good idea.
>
> - Jonathan M Davis
>
>
> P.S. I believe that the word that you were looking for was dissatisfaction, not
> unsatisfaction (which isn't a real word).
>    
I like it too.

A complimentary change is to automatically apply type modifiers when 
creating objects, but not when making references to them, like so:

immutable class Foo {...}
Foo foo = new Foo();

Here, the object on the heap would be immutable and foo would not.

Currently class (and struct) type modifiers don't get automatically 
applied - at least not in ways that I find useful, and I keep having to 
do laborious stuff like this, which I don't like at all:

synchronized class _Foo {}
alias shared(_Foo) Foo;
Foo foo = new Foo();

or even worse:

synchonized class Foo {}
shared(Foo) foo = cast(shared) new Foo();

-- 
Graham St Jack



More information about the Digitalmars-d mailing list