YACP -- Yet Another Const Proposal

[Bruno Medeiros]

This might have not been the best time to deal with this. This is a 
complex issue, people are very busy and the dust is just settling with 
regards to the import issues.
I myself have only read part of the Javari paper, not all yet. I hope to 
finish it at a later time, and eventually get back at this const issue.
Still, I've read your post and I'll give some initial comments.

Reiner Pope wrote:
> 
> *1. Mutability vs assignability*

I think that as a simplification, immutable variables should also be 
unassignable. That is, all readonly vars would be final as well. I have 
a feeling this would be beneficial.

> *2. Const by default*
> 

OK to me.

> *3. rocheck*
> 

I haven't read that part of the paper yet, but I think I get a good 
enough picture from your description.
And I think rocheck wouldn't fit well with D, due to the runtime checks 
and performance penalties, which, like you said, could not be disabled 
in release builds (as they are not contracts). Also, it would only work 
with classes, and not any kind of type.
(You have an example where you have a "rocheck char[]" variable, how 
would that work internally?)


> *4. rotemplate/romaybe*

This fits nicely with D, since D already has the notion of templates and 
templated functions, which is what rotemplate is (although the runtime 
function code is the same).

> *5. const type inference*
> This is just a mechanism for avoiding even more const attributes 
> scattered throughout the code. Since const is just an alteration to the 
> typing mechanism (at least, in Javari it is), type inference could be 
> used to change this code:
>   readonly char[] c = getSomeReadonlyFoo();
> into
>   auto c = getSomeReadonlyFoo();
> 
Hum, maybe. (see below)

> *Everything else*
> Static const-checking is done just as Javari, which means through the 
> type system, in which every immutable type is a superclass of a 
> corresponding mutable type, and casting is then allowed /to/ const, but 
> not /out of/ const (this operation must be done via duplication, or 
> dirty assembler hacks -- however, there should be enough flexibility 
> that workarounds are not required often).
> 

I don't like to think of a immutable type as a supertype of a mutable, 
although the semantics are the same.

> 
> *Side note*
> One more (slightly unrelated) possibility that this allows is declaring 
> utility functions as const, like toupper, etc. I haven't thought much 
> about the details, but this could allow, given some planning, a system 
> to ensure that a given function has no side-effects, which means it will 
> always give the same result given the same parameters. This can lead to 

No it wouldn't guarantee any of that (no side-effects). The function 
could access global variables, static variables, other functions, etc. 
(there are many things other than just the functions parameters)

----

*Overall Comments*

This seems like a good starting point for a const proposal. But we have 
to think of all aspects of how this would work with D. D is more complex 
than Java, and there are more things to consider when implementing 
immutability. In particular D is way more advanced in features that work 
with types, like templates, template specializations, typeof 
expressions, is expressions, etc., and we have to think how const would 
work with those, and see if it is all correct, solid and feasible, (and 
also if there is a better way).
For example, how about this:

Would the delegate literal syntax allow an immutable-this? Would there 
be syntax conflicts?
(I think there wouldn't be syntax problems)

How to use type inference to create a readonly view of some mutable data?
   immutable auto bar = somefoo.somebar; ?
   auto bar = cast(immutable) somefoo.somebar; ?

Would "typeof(foo)" include the constness of foo?
(Hum...)

Should another is-expression metatype check be added? How would it work?
   is(constof(foo) == immutable) ?
   is(typeof(foo) == immutable) ?
(Hum...)

How would template specialization work with constness?
  (T : Object)  -> specializes on any Objects or just mutable Objects?
  (T : T*)      -> specializes on any pointers or just mutable ones?

How to specialize on just mutable or immutables types?
  (T : mutable Object) ?
  (T : immutable Object)?
(as we can we probably we also need would a "mutable" keyword)


As you see there are still many details that must be considered. I think 
this is by far the most complicated proposal D will ever face.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D