Re: [Vala] Immutable variables

[pancake <pancake youterm com>]

On Fri, 15 Jan 2010 21:18:11 +0100
Jiří Zárevúcky <zarevucky jiri gmail com> wrote:

> pancake píše v Pá 15. 01. 2010 v 08:42 +0100:
> > Is there a way to define them? I need it to solve some warnings for  
> > the vapis describing some C functions accepting const char* as argument.
> >
> > As I see in the compiler source is that it is not supported. Only for  
> > struct or class definitions with [Immutable].
>
> Right, it isn't at the moment as far as I know.
>
> > Are there plans to support it for variables?if it is just to handle  
> > function signatures correctly..
>
> I'm all for it. [Immutable] attribute for parameters would do great IMO.
> Or perhaps immutable keyword as a type modifier? That would allow
> binding some non-trivial array types, but I'm not sure whether that's
> necessary.

I have some warnings related to this in the radare2 vapi bindings.

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.

I also like the 'immutable' keyword, but I think that Jürg said that he
prefered [Immutable] attribute before the variable name.

int write (int fd, [Immutable] void *buffer, int length);
int write (int fd, immutable void *buffer, int length);

for me, the second form is nicer, but this forces to create a new keyword
which is probably undesired, but if you try to use attributes somewhere
else than before a struct, class or method definition you get an error,
so it will not be backward compatible. 

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. Something like
a weak or unowned one, but with the property that no write operations can
be done on it.


--pancake