byval keyword to make objects act as value types

[BC]

On Sun, 23 Dec 2007 04:01:30 -0000, Christopher Wright  
<dhasenan at gmail.com> wrote:

> BC wrote:
>> so that 'byval MyClass' is a new type that acts like MyClass in all  
>> ways (ie. is polymorphic) except that it gets dupped on non-const  
>> assignment from other byval MyClasses and normal MyClasses. possibly  
>> also on assignment to normal MyClasses. this would require that it  
>> *has* a dup method, or maybe a copy constructor
>
> Perhaps this would be better as a class declaration modifier?
>
> byval class Foo {} // acts like a struct
>
> Or:
> valueclass Foo {}
>
> It would be simpler, at least: an opAssign overload.
>
true, it's just that I don't buy that classes are always either value or
reference types, I think flexibility is desirable. you could still do

class Foo{}
alias byval Foo VFoo;

>> byval Base b = new Derived;
>>  despite the name 'byval' b actually holds a reference to a copy of  
>> Derived, so slicing is avoided.
>> or, if that's too inefficient perhaps the linker can figure out the  
>> size of the largest class derived from Base and allocate that much on  
>> the stack/inside a containing class.
>
> If we get this, I'm going to ask for virtual template methods in classes  
> again. It's not happening.
>
no, i'm not holding my breath. it could for final classes though.

>> myFunction(ref Base arg)
>> {
>>    ++arg;
>> }
>>  myFunction(b)
>>  i'm thinking it should be overridable so that the above function  
>> *does* change the value of b
>
> Besides which, arg isn't assigned to...
>
> void func(ref ValueClass arg) {
>     arg = new ValueClass();
> }
>
>> question: are calls to final class member functions non-virtual?
>
> Well, yes. But do you mean, are they found in the vtbl? You could check:
> class Foo {
>     final void a(){}
>     final void b(){}
>     final void c(){}
> }
>
> assert (Foo.classinfo.vtbl.length == Object.classinfo.vtbl.length);
>
i should have said 'member functions of final classes'. both are found
in the vtbl. i was wondering how close to struct behaviour we can bring
classes.

>> i notice the tango iterators are classes. surely we want to use  
>> iterators as value types... this way, we can.
>>  alternatively, since scope objects are a bit like value types already,  
>> perhaps we can just add the functionality to that.
>
> Ugh. No.
>
no? currently the spec says you can't assign to them (although i see now
that you can), so i thought that might be the plan.

>> then, we just need to return refs from functions, and it's goodbye C++!