Hmm - about manifest/enum

[Steven Schveighoffer]

"Bruce Adams" wrote
>On Wed, 02 Jan 2008 17:53:28 -0000, Steven Schveighoffer wrote:

>> If you do:
>>
>> setValueTo5(T)(T x)
>> {
>>    x.value = 5;
>> }
>>
>> If T is a class, then it affects data outside the function.  If T is a
>> struct, it does not.  We have to know if T is a class or not.
>>
> Unless the struct contains a pointer or class reference :)
>
> You seem to be talking about purity rather than constness here.

This example has nothing to do with const :)  What I'm talking about is the 
argument against my idea.  The argument is that it is impossible to 
implement a tail-const reference to a class because anything you do results 
in you having to know whether a generic type is a class or not.

For example, if const(*C)* is a tail-const reference to a class C, then the 
generic code:

f(T)(const(*T)* x) {....}

Will only compile for T's that are reference types (i.e. classes or 
pointers).  The argument is that this is not desired, because no matter what 
we do, we should be able to substitute any type in there and have it work.

My counter-argument is that there are already inconsistencies between 
classes and structs and primitives, in that classes are references and you 
have to treat them as such.  Since we may already need to check if a type in 
a template is a reference or non-reference type, the original argument that 
my const ideas cannot be implemented is contradictory.  You can't say the 
new behavior violates some rule when the current behavior already violates 
that rule.  My point is, the rule is incorrect, not the behavior.

-Steve