[Vala] Fwd: Immutable variables

[Fredderic Unpenstein <magentus gmail com>]

One of these days I'll get the hang of this annoying thing, and stop
replying to posts personally.  Or get a real client going again.
(Reposted to the group)


2010/1/17 pancake <pancake youterm com>:
> For example, you have a function that returns a const buffer, which is
> contained in a read-only section. If you get this buffer from vala, there's
> no way to represent that situation, so you are asigning a const buffer to
> a non-const buffer which results in a warning and the possibility to try
> to modify this buffer which shouldnt be permitted.

So shouldn't const be fixed, instead of adding immutable?  The process
of making a const value writable, is simple; copying it to another
location.  Works on absolutely anything.  The same process, as owning
a non-refcounted value.  So a const unowned buffer would fulfill your
requirements - no modify and no free.  It's a little long-winded,
perhaps, but not much more so than immutable (four characters, by my
reconning).


What I *would* like to see, is an immutable keyword that treats values
without exclusive ownership (defined as exactly one reference; that of
the containing variable) as const.  Basically, anywhere that const
would be violated, perform an exclusive-ownership test, and replace
our reference a brand new copy if needed.  If we DO have exclusive
ownership, then modify away to your hearts content. It COULD even
cause automatic boxing of any non-refcount'd values as a handy
side-effect.

The difference between this and const unowned, is that it's a property
of the value itself, rather than the variable.  This causes more
checking if you're doing a lot of writes - not what this kind of flag
is intended for - but nothing other than basic reference counting if
you're only reading, and without prohibiting writes entirely.


> For methods like this:
>
>   immutable string get_description ();
>
> the compiler should understand that the returned string shouldnt be modified,
> so it doesnt requires to be freed and cannot be modified.

That still seemes like the job of const and unowned.  Just because a
value can't be modified, doesn't mean it shouldn't be free'd, or vice
versa.  Immutable as I've put it, allows for a value to be shared
infinitely without copying, like const unowned, but also modified
without affecting other users at a small modify-time cost.


Fredderic