From -5410757214026473005
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,aef96954609d602c
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-08-17 13:05:46 PST
Path: gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!pipex!sunic!news.lth.se!dag
From: dag@control.lth.se (Dag Bruck)
Newsgroups: comp.std.c++
Subject: Re: Template constraints
Date: 17 Aug 1993 18:52:08 GMT
Organization: Department of Automatic Control, Lund, Sweden
Lines: 29
Message-ID: <24r9co$6ca@nic.lth.se>
References: <744662863@amazon.cs.duke.edu> <rfgCBtK36.JMB@netcom.com> <745511175@amazon.cs.duke.edu> <rfgCBv43v.LJB@netcom.com> <26326@alice.att.com>
NNTP-Posting-Host: control.lth.se

In <comp.std.c++> ark@alice.UUCP () writes:
>
>One way of solving this problem, which I think I and several other people
>have suggested independently, is something like this:

[Summary of proposal.]

	class T;

	means that T is a some type.

I think this is a bad idea, because T may not necessarily be a class,
struct or union:

	typedef int T;
	....
	class T;		// yuck

I think this is not quite intuitive and blurs the distinction between
built-in types and classes.  Do we want this distinction?  Maybe not,
but I belive that people would for example expect to be able to derive
new classes from something called "class."  I still prefer

	typedef T;

inspite of the problems incurred by "implict int."


			-- Dag


