Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!raeburn
From: raeburn@athena.mit.edu (Ken Raeburn)
Newsgroups: comp.std.c++
Subject: Re: "module" facility for top-level namespace control
Message-ID: <RAEBURN.91Apr26165646@watch.mit.edu>
Date: 26 Apr 91 20:57:43 GMT
Article-I.D.: watch.RAEBURN.91Apr26165646
References: <1991Apr19.163253.22253@kestrel.edu>
	<1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM>
	<1358@appli.se> <1991Apr25.060721.12694@alias.com>
Sender: news@athena.mit.edu (News system)
Distribution: comp.std.c++
Organization: Massachusetts Institute of Technology
Lines: 52
In-Reply-To: rae@alias.com's message of Thu, 25 Apr 91 06:07:21 GMT

In article <1991Apr25.060721.12694@alias.com> rae@alias.com (Reid Ellis) writes:

   Scott Layson Burson <gyro@kestrel.edu> writes:
   |Suppose we were to introduce a keyword "module" with a simple syntax:
   |   module Foo {
   |     // ... declarations
   |   }

   Ron Guilmette <rfg@NCD.COM> writes:
   |how about just using `class <identifier> static { ... }' rather than
   |requiring `module <identifier>'?

   Niklas Hallqvist <niklas@appli.se> writes:
   |How about:
   |
   |default class CLASSNAME-LIST {
   |  // code goes here;
   |}

   I'd like something similar to Ron's idea, but the other way around:

   static class <identifier> {
	   // ...
   }

   Did you know that the above currently passes cfront without a peep?
   The "static" doesn't actually *do* anything, but nothing complains.

This is probably because
	static class X { ... } x;
would be a valid declaration.  It wouldn't be unreasonable for the
translator to complain about storage-class specifiers used in empty
declarations, but I wouldn't expect it.

   This could be more generally defined as any storage-specifier
   preceding a class definition becomes the default storage-specification
   for the scope of the class?

You could only do it for otherwise-empty declarations, and then the
result depends on whether an identifier name follows the class body.
Bletch.

Ron's suggestion works best of those above, in my opinion, because the
construct (specifically the placement of "static") bears little
resemblance to existing constructs.  The one Niklas proposes, if (as
he suggested) the "class" keyword becomes optional, might confuse a
compiler trying to do error recovery (e.g., from a missing ":" after
"default").

I haven't thought about it enough to know which suggestions I like as
a user of the language.  I've spent plenty of time recently dealing
with the g++ grammar, though.