constness for arrays

[Andrew Fedoniouk]

"Johan Granberg" <lijat.meREM at OVEgmail.com> wrote in message 
news:e9m79k$2sf$1 at digitaldaemon.com...
> 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)

Johan, you've got it right.

>
> 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.

Exactly. The main purpose is not for extending classes but to
give opportunity to extend intrinsic and value types.
It makes real sense for arrays, integers, enums, etc.

Again, external methods for arrays are here anyway - this
is good chance to legalize them.

>
> 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.

Exactly!

Consider this
typedef uint color { ubyte red() {....} }
I want to keep color all attrributes and operations of uint but to
give it couple of specific methods. The thing is that declaration
of such type will force all methods to be declared in one place.
Intellisense engine will like such declarations....

>
> /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.
>

Yep. You've got an idea. sub- and super-sets are right words.

Andrew Fedoniouk.