In article <3fmbfr$ngd@panix.com> isi@panix.com (Atman Jacob Binstock) writes:
>Has there been a proposal to allow the property of constness to be a
>template parameter?  Something that would allow something like this:
>
>template<class T> class Array {
>...
>        template<constness C> C T& operator[](int i) C { return A[i]; }
>...
>        T* A;
>};
>
>I'd welcome some suggestion that does not involve (source) code
>replication or casting...

 Nope. On the other hand I am doing everything I can to
ensure there is NO WAY that you can make "T" anything but
an unqualified type. So for functions, you would HAVE to
overload templates, with one version for every possible
qualification (if you wanted that).

 I'd like to make you define distinct classes too.
(You cant overload them).

 At present it is permitted to explicitly bind a template
parameter to a const type. It is a fairly dangerous practice,
I recommend against it. More important, it is not clear
whether and how a const type can be deduced by type deduction on
a function call. It seems fairly important that it is not
possible for this to happen. In particular, it is not clear
that it makes the slightest sense in the case

 template<class T> void f(T);
 f(1); // f(const int)??????

and it is probably quite dangerous in the case

 template<class T> void f(T&);
 int const x;
 f(x); // calls f(int const&)??????

Unfortunely, the way the rules are written up in the Working
Paper it is not at all clear what can and cannot be deduced.

I suspect an extension supporting "constness" as you describe
will not be all that useful, however it may be safer than
permitting "T" to be a qualified type. If such an extension
were to be added, we'd probably need more than just a symbol
taking on the qualifiers of an argument type. You'd
probably want to "convert" them by removing, or reversing
some of them with some kind of "algebra" of qualifiers.
Possibly, considering the qualifiers as a subset of {const, volatile}
suggests how to construct a coherent and complete algebra.

For example:

 ~C // turns "const" into "volatile": complement
 C+const // turns volatile into const volatile: union
 C*const // removes "volatile": intersection

For example, to cast away const:

 template<class T, constness C>
 C-const T castaway(C T *t) {
  return const_cast<C-const T*>(t);
 }

Unfortunately, template only support "conditional" code
generation by overloading. Since that is what is required
in general, you need to use overloading really.:-(



--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

isi@panix.com (Atman Jacob Binstock) writes:

>Has there been a proposal to allow the property of constness to be a
>template parameter?

I think it's been informally suggested once or twice.

>I'd welcome some suggestion that does not involve (source) code
>replication or casting...

There's always macros ;-)

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

Has there been a proposal to allow the property of constness to be a
template parameter?  Something that would allow something like this:

template<class T> class Array {
...
 template<constness C> C T& operator[](int i) C { return A[i]; }
...
 T* A;
};

I'd welcome some suggestion that does not involve (source) code
replication or casting...
Thanks,

--
Atman Binstock                                       Integrated Software Inc.
isi@panix.com                                        speaking only for myself