Do we really need const?

[Reiner Pope]

Bruce Adams wrote:
> Bill Baxter Wrote:
> 
>> Bruce Adams wrote:
>>> Janice Caron Wrote:
>>>
>>>> On 9/18/07, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
>>>>> Janice Caron wrote:
>>>>>> About passing structs by reference: It's one of those things, like
>>>>>> register or inline...
>>>>>>
>>>>>> Once upon a time, programmers used the keyword "register" because they
>>>>>> thought they could do a better job than the compiler at figuring how
>>>>>> to use its registers.
>>>>>>
>>>>>> Once upon a time, programmers used the keyword "inline" because they
>>>>>> thought they could do a better job than the compiler at figuring out
>>>>>> what to inline and what not.
>>>>>>
>>>>>> Now people explicitly choose between f(s) and f(ref s) (where s is a
>>>>>> struct and the function does not modify it) because they think they
>>>>>> can do a better job than the compiler at figuring out how to pass
>>>>>> parameters to functions. I say give control back to the compiler. Lets
>>>>>> let "ref" mean "the function may modify the parameter", and the
>>>>>> absense of ref mean "the function may not modify the parameter", but
>>>>>> leave it to the compiler to decide what is the most efficient way to
>>>>>> pass the data to the function.
>>>>> This thought has occurred to me before to.  I think issue becomes that
>>>>> the function signature may no longer enough for a compiler to tell what
>>>>> kind of code it needs to generate to call the function.
>>>> Actually, I think it's possible my proposal may not have been
>>>> understood. Under my suggestion, if the caller passes a struct...
>>>>
>>>> f(s)
>>>>
>>>> ...and the callee declares the function as...
>>>>
>>>> void f(S s)
>>>>
>>>> ...then all information is known. Both ends must surely know s.sizeof
>>>> at compile time? And since that's the /only/ thing the compiler needs
>>>> to know to make the decision.
>>> S could be an opaque type so s.sizeof may still be undefined.
>> You can't declare a function that takes an argument of unknown size. 
>> You just can't.  The compiler will complain that it doesn't know the 
>> type.  So either your "opaque type" is not allowable, or it's actually a 
>> reference/pointer to "opaque type" in which case the size of the pointer 
>> *is* known, which is all that is needed, since that's all that will be 
>> passed to the function.
>>
>> --bb
> 
> See my reply to Janice on channel B.
> I did mean its passed by reference. I don't quite get the structs are passed by value by default thing. 
> I'm assuming everything is passed by reference by default but that sometimes you want the compiler to pass by value as for small data types by they classes or structs its more efficient. So my point is that for an opaque type you may not have access to sizeof.
> 
> An opaque type is like a class or struct whose data members are all private but done properly. You don't need to know about the implementation. C++ forces you to expose the implementation by declaring the members in the header even though they're private and client code can't do anything with them. The caveat is you do still need to know the size to reserve space for an opaque type before its constructed. This is why a C++ compiler needs a full definition. In theory it could be sorted at link time with support from the object file format or even left until run-time. My understanding was that you can do opaque types properly in D though I haven't tried myself. So you have sizeof at link time but not necessarily at compile time.
> 
> Regards,
> 
> Bruce.

These opaque types sound suspiciously like D classes/interfaces.

void foo(Object o)
{
     assert(o.sizeof == (void*).sizeof);
}

But C++ polymorphism also allows that, no?

But, as other people have pointed out, doing this with structs is a 
completely different story.

    -- Reiner