Re: type constraint specification

From: dexsch (DavidS_at_[hidden])
Date: 2002-02-20 00:07:08

--- In boost_at_y..., "Noah Stein" <noah_at_v...> wrote:
> > -----Original Message-----
> > From: dexsch [mailto:DavidS_at_a...]
> > Sent: Tuesday, February 19, 2002 5:48 PM
> 
> >
> > Here is an example of a meta type definition.
> >
> > // This says ListNode types must
> > // declare a typedef value_type,
> > // have a copy constructor,
> > // and a next() method which returns a ListNode*
> > // and an equality comparison operator
> > // Remember the name ListNode is a place holder
> > // for the actual type(s) being constrained
> > typespec ListNode
> > {
> > public:
> > 	typedef value_type;
> > 	ListNode(const ListNode&)
> > 	ListNode* next();
> > 	bool operator==(const ListNode&)
> > };
> 
> 
> I like the idea here, but I would prefer a notation that does not 
introduce
> a keyword.  I would suggest using a notation similar to that used 
by pure
> virtual functions:
> 
> typename ListNode = 0
> {
> public:
> 	typedef value_type;
> 	ListNode(const ListNode&);
> 	ListNode* next();
> 	bool operator==(const ListNode&);
> };
> 
> The issues I still see with the above is that the "typedef 
value_type;" is
> different than the normal syntax for typedef.  Which leads me to 
another
> suggestion.  I think that there should be some type of ANY class 
designation
> like that in Eiffel.  It's a great way to specify a completely 
abstract
> concept without resorting to using many template parameters and the
> curiously recurring template pattern.
> 
> >
> > // This says the LinkedList template class
> > // accepts only types that satisfy the ListNode typespec
> > template <ListNode T>
> > class LinkedList
> > {
> > 	...
> > };
> >
> 
> I don't think the proposed notation would work as-is.  What if the
> requirements on T are that it be a ListNode and, say, 
Serializable?  Maybe
> something such as:
> 
> template< class<ListNode,Serializable> T>
> class LinkedList
> {
> 	...
> };
> 
> 
> 
> -- Noah
The inheritance scheme for type constraint specifications,
would also allow the imposition of rules which would prevent
silly mistakes like, overloaded names in constraints, or
one rule requiring a copy constructor and another banning it.

This raises the need for a NOT operator within a typename declaration.
eg.
// No copying or assignment allowed
// notice the tilde ~ in front of the negated names
typename NoDuplication
{
  ~NoDuplication(NoDuplication&);
  ~NoDuplication(const NoDuplication&);
  NoDuplication& ~operator=(NoDuplication&);
  NoDuplication& ~operator=(const NoDuplication&);
};

No usage conflict could arise since it is an error to
want to disallow a destructor or enforce a requirement
for a destructor (since one is always provided for every class).

I think that the public: declaration inside a typename
declaration is redundant since it only makes sense to
put constraints upon the public interface of a class.
This also closely parallels traits declarations
which usually only have public members.
I shall not go into the possible meaning and uses
of protected and private traits members.

A consequence of the removal of access specifiers
is that friend declarations fall outside the scope
of typename declarations. I dislike friend declarations
with a passion anyway.

dex