🚀 go-pugleaf

In article <mkohtala.726108774@vipunen.hut.fi> Marko.Kohtala@hut.fi suggests
the use of Class::{ /* ... */ } as syntactic sugar so that class members
could be defined in the scope without the need to explicitly put the class
prefix on each member.  He argues that this would make the code easier to
write and maintain.

His example is that
>
>Class::{
>  int var;
>  int func1() { /* ... */ }
>}
>
>... would be treated as
>
>int Class::var;
>int Class::func1() { /* ... */ }

I don't know if I agree with that reason, but I would like to see something
like this as a clean way to allow ``helper functions'' in the implementation
of the class.  This particular syntax has the advantage of being intuitive,
since ``Class::'' already means ``open the class scope in this context'' in
other places.

The semantics would be that all names defined in the scope would be visible
within the scope (subject to the usual scoping/visibility rules, of course);
names that were declared in the class description would be the only ones
exported from the scope.  This would allow a helper function to be defined
that had full access to the class private members, but still be type-safe,
since the only way to access the helper functions would be from within the
scope and the only way to enter the scope would be via the class interface.

That is,
	class Class {
	public:  int func1();
	};
	Class:: {
		int helper() { /* ... */ }
		int func1() { /* code including calls to helper() */ }
	}
Since helper() is not declared in the class, it is not exported from the
scope, while func1() is declared in the class, so it is exported in the
normal fashion.

I like it.  It's a way of sneaking up on modules/packages without adding
any new tokens to the language.

It does have the disadvantage that it makes the language larger.  On the
other hand, it would seem to eliminate the desire, expressed by several
people, for nested functions.  Such nested functions would usually be
helper functions in the implementation of a class, so by being able to
expand the class context to include non-nested functions would provide
an efficient solution.

So what do other people think?  It may be (probably is?) too late to
include this in the current C++ standardization effort, but if there is
some consensus that this syntax is reasonable, it might be possible to
nudge some vendors to try it as an extension.  (If it isn't too late,
how would I go about proposing it to the standards committee?)

If you grant that helper functions are needed, but don't like this idea
because it adds to the size of the language, an alternative would be to
take something that is syntactically legal but semantically forbidden and
define semantics for it.  I have thought about
	static /* type */ Class::Helper( /* params */) { /* ... */ }
which currently has no semantics (class functions cannot be defined as
static) and treat it as if it were declared (at file scope) as a private
member of the class.  It would only be accessible to members and friends
within the same file, so it too should be type-safe.
-- 
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com