Extended Type Design.

[Reiner Pope]

Andrei Alexandrescu (See Website For Email) Wrote:

> 
> We have talked about a design. In short, the intent is to define three 
> flavors of immutability:
> 
> a) final - a simple storage class controlling the immutability of the 
> bits allocated for the symbol per se;
> 
> b) const - type qualifier meaning an immutable view of an otherwise 
> modifiable data. const does not control the bits of the object, only the 
> storage addressed indirectly by it (transitively);
> 
> c) "superconst" - denoted as "const!" or "super const": type qualifier 
> meaning that the data is genuinely unmodifiable.
> 
Is there anything in your discussion about compile-time constants (the sort that you need for 'static if', etc) ? You spoke a while ago about improving compile-time evaluation syntax so that there would be no difference at the call  site between runtime and compile-time evaluation (like for regexps).

It seems like you could get this quite easily by adding just one more parameter modifier (is this a storage class? I'm not sure) to denote, "any time this function is called, this parameter must be known at compile-time". Effectively, it would just be a conversion from this:

RegExpMatch match(static const char[] pattern, char[] text) {...}
...
main()
{
     match("gr[ae]y", din.read());
}

to this:

RegExpMatch match(char[] pattern)(char[] text) {...}
...
main()
{
     match!("gr[ae]y")(din.read());
}

Any plans this way?

Cheers,

Reiner