Article View: comp.std.c++
Article #1045Re: "module" facility for top-level namespace control
From: Ken Raeburn
Date: Fri, 26 Apr 1991 20:57
Date: Fri, 26 Apr 1991 20:57
52 lines
2731 bytes
2731 bytes
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.
Technical Details
Message-ID:
<RAEBURN.91Apr26165646@watch.mit.edu>Path:
arc1-ca.pugleaf.net!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!raeburnReferences:
<1991Apr19.163253.22253@kestrel.edu> <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM> <1358@appli.se> <1991Apr25.060721.12694@alias.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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