constness for arrays

[Johan Granberg]

xs0 wrote:
> But you can also not define opSliceAssign in struct string, and get the 
> compile time error?

I think you are missing the point of this proposal (which I like a lot 
by the way).

(Andrew Fedoniouk if I have missinterepted your proposal, pleas excuse me)

The purpose is not to extend a type as with a class inheritance or to 
create a new type as with a new class or struct, but to alter the 
behavior of an existing type to allow for things like read only and 
color types that can bee passed as is to common graphics api's that 
expects uints etc.

This would add missing power too the language that are not available at 
the moment. An alternative weaker (but in my opinion worse) syntax to do 
this would be this.

struct string : char[]
{
	//posibly
	override opSliceAssign(){throw new Exception("");}

	//or
	disable opSliceAssign();
}

Here we introduce struct inheritance and the use of built in types as 
base classes but due too the extending nature of inheritance (the child 
beeing a superset of the parent) the disable syntax is bad and the use 
of inheritance forces the use of the virtual table (which structs and 
inbuilt types don't have).

The proposed syntax allows for this on the other hand

typedef char[] string
{
	disable opSliceAssign;
	string toLower(){..}
}

If we used inheritance this would not bee possible because we remove 
opSliceAssign from the interface of the type.

Here we use the new syntax to describe a "starting from" relation ship 
while inheritance creates a is a relationship.

We could create an entirely new type using structs and so on but the we 
would have to specify all the methods and fields of the new type rather 
than our changes. This is very much against the principles of code reuse.

/Johan Granberg

ps. Walter this could bee a nice feature to have as it would allow the 
creation of subsets of types (and intersecting types) as well as supersets.