byval keyword to make objects act as value types

[BC]

On Sun, 23 Dec 2007 05:40:34 -0000, BC  
<NOTmi_emayl_adrez at hotmail.com.remove.not> wrote:

> On Sun, 23 Dec 2007 05:09:43 -0000, BC  
> <NOTmi_emayl_adrez at hotmail.com.remove.not> wrote:
>
>> 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();
>>> }
>>>
> i didn't realise you could have a reference to a reference
>
>>>> 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.
>>
arrghh. only in the vtbl if overriding a base class function, as they have
to be really. but not called virtually from references to the final class/
class in which they are final.

>>>> 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, if you like access violations), so i thought that might be
>> the plan.
>>
> don't forget that if you assign it to something else such as a scope  
> object
> inside another class, you get a copy, which won't get destroyed,
> so they could then outlast the function scope and be just like a value
> type as far as i can see.
>
>>>> then, we just need to return refs from functions, and it's goodbye  
>>>> C++!
>>
>