a more consistent const syntax

Daniel919 Daniel919 at web.de
Sun Aug 5 05:42:09 PDT 2007


I've got some ideas about how to make the const syntax more
consistent.
First I will show you the current situation.
Then I will list the confusions and possible solutions.

Some days ago I already mentioned my first idea on IRC, but got no replies.
Also I know that you, Walter, hardly don't change features, which
already have been implemented.
And my suggestions would require this of course.

The "define proposal" is not such a big change in the language,
in opposite to the much more important idea about
"putting the return type in a bracket at the end".
Because this is what the last idea requires, it's written after "WAIT:".

Nevertheless I will give it a try, because 2.0 is still alpha and it 
will break code compatibility anyway.



currently the keyword const(/invariant) has three meanings:
-----------------------------------------------------------
1. alone: const x = 1; compile-time variable (not an lvalue)
2. with(): const(P) p = new Point(1,2); run-time object, which is 
protected from changes
3. alone: const P func(P p) { writefln(p.x, " ", p.y); }; attribute for 
a member function: the function can't change any class fields


confusions and solutions:
-------------------------
#1
1. const x = 1;
2. const(P) p = new Point(1,2);
you see const first and later recognize the brackets
one would not expect brackets to lead to a completely different meaning 
of the forrun keyword

1. define x = 1;
2. const(P) p = new Point(1,2);
can't be confused anymore, different keywords
define defines a compile-time variable
const / invariant has nothing to do with compile-time anymore. it only 
means protection


#2
3. const P func(P p) { ... }
reads like: func returns a const(P)

const / invariant alone (without brackets) is an attribute and has no 
other meaning
further proposal: returned types in a bracket at the end:
3. const func (P p) (P) { ... }
//templated syntax: const func!(T) (T p) (T) { ... }


#3
1. same meaning: invariant x = 1; const x = 1;

not allowed anymore: const(/invariant) alone is an attribute, instead use:
1. define x = 1;


#4
//this is ok: final int x = 1; const(int)* xptr = &x; // but:
2. const(int) x = 1;
this is nonsense and also atm it could be confused with:
1. const int x = 1;

the compiler should issue at least a warning, and instead you should use:
1. define x = 1;


#5
void func(const P p) { typeof(p) == const(P) }
bad, because one could expect this to be also valid then:
const P p = new P(1,2); //but fails of course
correctly is has to be:
void func(const(P) p) { ... }
void func(ref const(P) p) { p = new P(3,4); } //OK
//void func(const(int) i) { ... } //const(int) nonsense (see #4)
//void func(ref const(int) i) { ... } //const(int) nonsense (see #4)

compiler should issue an error
const(/invariant) alone is an attribute


WAIT:
-----
because we have another syntax for compile-time variables now,
we could say that:
const P** ptr2ptr2P means:
const(P**) ptr2ptr2P
in this case, #5 would be allowed
but this would also require #2 further proposal to be implemented, 
because if it wasn't:
const P** func() { ... }
would not only be confused with, but it would be THE SAME as:
const(P**) func() { ... }
then the correct form would have to be:
const func() (const P**) { ...}

note that #4 would be true for: const int x = 1; then
this would be nonsense, because it would be the same as: const(int) x = 1;
so the compiler should issue at least a warning



PS: Having the return types in a bracket at the end, would make it
possible to implement multiple return values / return tuples
in a consistent way, too.
It would also allow more tricks, like returning local values of a 
function, avoiding ref, etc etc ...



I would really enjoy to get some replies (especially yours, Walter),
even if it's just a: "No that's totally stupid" ;)

Best regards,
Daniel



More information about the Digitalmars-d mailing list