pragma wrote:
>>Examples:
>>// analog for typedef int MyInt
>>struct MyInt: int {}
>>
>>//  ( super is just shortcat for cast(int*)this )
>>struct SmartInt: int {
>>    public SmartInt opPos(){ // change opPos into an absolute-value
>>    operator
>>        if(*super < 0) return(-*this);
>>        return(*this);
>>    }
>>}
>>
>>// static array
>>//  ( using template syntax )
>>struct AutoSumIntArray(N): int[N] {
>>    private int _sum = 0;
>>    int sum() { return _sum; }
>>    int opIndexAssign(int val, int idx) {
>>        _sum -= (*super)[idx];
>>        (*super)[idx] = val;
>>        _sum += (*super)[idx];
>>    }
>>    int opSliceAssign(...) { ... }
>>}
>>
>>// dynamic array
>>//   must use class syntax becouse of reference semantic
>>class BoundedIntDynArray: int[] {
>>    int bound = 100;
>>    this(int l) {
>>        if(l > bound) assert(0);
>>        super(l);
>>    }
>>    void length(int l) {
>>        if(l > bound) assert(0);
>>        super.length = l;
>>    }
>>}
>>
> 
> This could work, but the only problem is that you loose implicit casting since the memory footprint of some of your examples are not the same as the underlying
Only if I add new data members.

> type.  But then again, you'd have to use the typedef explicitly (casting and whatnot) to get the functionality you need, so I guess there's little difference.  This way you get shorthand-templating for 'free' which is a huge plus. (use of 'super' is nice too)
> 
> As long as you get to inherit the base scalar's operators and properties,
> I
> honestly don't care which style makes it through.  Its too useful a
> construct not to have. :)
Absolutely agree.

-- 
          Vladimir

Vladimir wrote:
<snip>
> If we allow struct inheritance by means of just adding base struct members
> to the front of child struct, and allow struct inheritance from basic types
> it would solve the problem.
> Casting child struct to base struct can be allowed, but all struct methods
> must be treated as non-virtual, so we can keep compitability with C
> structs.
> 
> Examples:
> // analog for typedef int MyInt
> struct MyInt: int {}
> 
> //  ( super is just shortcat for cast(int*)this )
> struct SmartInt: int {
>     public SmartInt opPos(){ // change opPos into an absolute-value operator
>         if(*super < 0) return(-*this);
>         return(*this);
>     }
> }
<snip>

This is like an idea that I thought of, though on existing structs/unions rather than primitive types.

Under my idea, the derived type would be a union rather than a struct. This is because with the way D works, it doesn't make so much sense to add data members - since structs have value semantics, increasing the size means that it isn't really a value of the base type anymore.  OTOH it does make a bit of sense to add methods and/or views of the data to an existing struct (such as one defined in an external API).

But I guess this idea could work on built-in types as well....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Vladimir wrote:
> <snip>
>> If we allow struct inheritance by means of just adding base struct
>> members to the front of child struct, and allow struct inheritance from
>> basic types it would solve the problem.
>> Casting child struct to base struct can be allowed, but all struct
>> methods must be treated as non-virtual, so we can keep compitability with
>> C structs.
>> 
>> Examples:
>> // analog for typedef int MyInt
>> struct MyInt: int {}
>> 
>> //  ( super is just shortcat for cast(int*)this )
>> struct SmartInt: int {
>>     public SmartInt opPos(){ // change opPos into an absolute-value
>>     operator
>>         if(*super < 0) return(-*this);
>>         return(*this);
>>     }
>> }
> <snip>
> 
> This is like an idea that I thought of, though on existing structs/unions rather than primitive types.
> 
> Under my idea, the derived type would be a union rather than a struct. This is because with the way D works, it doesn't make so much sense to add data members - since structs have value semantics, increasing the size means that it isn't really a value of the base type anymore.
In any case defining new type you loose implicit casting to base type. In what situation size difference could cause a problem ?

> OTOH
> it does make a bit of sense to add methods and/or views of the data to
> an existing struct (such as one defined in an external API).


> 
> But I guess this idea could work on built-in types as well....
> 
> Stewart.
> 

-- 
          Vladimir