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 <[email protected]>: > 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 _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
