With arrays and pointers, you can declare

    const(int[]) constData;
    immutable(int[]) immutableData;

to enforce constancy constraints.  The type modifiers apply both to the reference to the data and to the data being referenced.  If you want to be able to change what data the variables reference, just not change the data itself, no problem:

    const(int)[] constData;
    immutable(int)[] immutableData;

However, this can't be done with classes.  You can't do it with language builtins, anyway.  Rather, a class object reference is either mutable, const or immutable, and this simultaneously affects both the reference itself and the referenced object.

This is unideal.  Whether a reference to an object can change what it refers to and whether the object itself can change are two distinct concepts.

OK, so we have std.typecons.Rebindable.  But I've found it a PITA when it comes to generic programming.  Among other things, if you try to pass it around, you can end up with a mess like const(Rebindable!(const(....))).  This wouldn't happen with built-in tail const support.

I guess that, at the code level, tailConst and tailImmutable would be just type modifiers.  But at the semantic level, they're just the const and immutable modifiers we already have being applied at a different level.  So:

- tailConst(int[]) would be equivalent to const(int)[]

- tailConst(Class) would be a whole new type modification, under which the reference can be reassigned, but the object's state cannot be changed through this reference, and when calling methods of it the this pointer is const.

- const(tailConst(anything)) would just be the same as const(anything)

- tailConst(Struct) would just collapse to Struct if the struct contains no references or only const and/or immutable references.  Otherwise, it would be a distinct type modifier that forces all references within the struct to be const.  (Should we allow struct methods to be qualified as tailConst/tailImmutable?)

- tailImmutable would work in the same way.

- You could have more involved constructs like const(tailImmutable(Class))[].  This would be an array of constant references to immutable objects.  So through this array reference, neither what objects are in the array nor the objects themselves can be changed.  But there may also exist a tailImmutable(Class)[] referencing the same block of memory, through which what objects are in the array can be changed, but the objects themselves remain immutable.

So essentially, where the columns denote top-level constancy and the rows the next level down:
          | mutable         const                  immutable
----------+-------------------------------------------------
mutable   | <no mod>
const     | tailConst       const
immutable | tailImmutable   const(tailImmutable)   immutable


Moreover, who thinks it would be nice if immutable classes could behave just like primitives?  Java gets partway there with String and others - you can just declare a String variable and assign to it as you would an integer, and be confident that some outside process won't change the contents of the variable behind your back.  D could be there with such improvements as built-in tail immutable (and making it the default modifier when a variable of an immutable class is declared).


What do people think to the whole idea?

Stewart.

I'm pretty sure there's a dmd pull request or
patch or something for this already.

IIRC Michel Fortin implemented it as Object ref obj;
(which is the same as Object obj;) and const(Object) ref obj;
as tail const.

Don't know where it is now though...

Stewart Gordon:

> OK, so we have std.typecons.Rebindable.  But I've found it a PITA when it comes to generic programming.  Among other things, if you try to pass it around, you can end up with a mess like const(Rebindable!(const(....))).  This wouldn't happen with built-in tail const support.

This is only partially related to your post. It's for a general solution.

Is it possible to invent a language construct that allows:
const(Rebindable!(const(....)))
To be defined as the same as:
Rebindable!(const(....))

Something like an onConst()/onImmutable templated methods for structs/classes?

Bye,
bearophile

On Wednesday, 28 March 2012 at 14:11:10 UTC, Adam D. Ruppe wrote:
> I'm pretty sure there's a dmd pull request or
> patch or something for this already.
>
> IIRC Michel Fortin implemented it as Object ref obj;
> (which is the same as Object obj;) and const(Object) ref obj;
> as tail const.
>
> Don't know where it is now though...

One of the first pull requests

https://github.com/D-Programming-Language/dmd/pull/3

Stewart Gordon, el 28 de marzo a las 14:54 me escribiste:
> What do people think to the whole idea?

I think this is not an announcement at all and shouldn't be discussed in this list :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Soy como una mosca, parada en el agua.
Y vos sos un transatlántico, querés nadar a mi lado.
Y me estás ahogando.

I'm not sure how my post ended up in .announce, but anyway....

On 28/03/2012 15:24, bearophile wrote:
<snip>
> Is it possible to invent a language construct that allows:
> const(Rebindable!(const(....)))
> To be defined as the same as:
> Rebindable!(const(....))

You mean be defined the same as
const(...)
?  It's the only thing that makes sense.

> Something like an onConst()/onImmutable templated methods for structs/classes?

Maybe something like

struct Rebindable(T) {
    alias const(T) onConst;
}

which would make const(Rebindable!(T)) just const(T)?

I'm not sure whether this would be a good idea.  And it would solve only one of Rebindable's many shortcomings....

Stewart.

On 28/03/2012 16:09, Stewart Gordon wrote:
<snip>
>> Something like an onConst()/onImmutable templated methods for structs/classes?
<snip>
> I'm not sure whether this would be a good idea. And it would solve only one of
> Rebindable's many shortcomings....

Moreover, any feature that makes a type a completely different type if constancy is applied to it could be abused in all kinds of ways, as well as breaking generic programming.  And I can't see any other genuine use case it might have.  On this basis, we might as well just implement built-in tail const instead.

Stewart.