Bruno Haible <[email protected]> writes: > Arsen Arsenović wrote: >> It's not reasonable to expect headers not to use the identifier 'T' I think. > > Well, the GNU libstdc++ uses only identifiers that start with '_' as > template parameter names:
Yes, because it has to presume the user defines any non-reserved
identifier.
That's because it's an implementation of the standard libraries.
Constraints placed on it are far more general than constraints placed on
application code by developers of application code.
In the latter circumstances, we can invent and enforce useful
conventions; libstdc++ cannot.
>> _T_ is a reserved identifier; all identifiers starting with an
>> underscore followed by a capital letter are. See [lex.name]p4.1
>
> Yes, this (practically) guarantees that application code will not be using
> '_T_'. Thus Gnulib can use it.
It also makes the program invalid ("shall not be used otherwise; no
diagnostic is required", "no diagnostics required" is standardese for
"you're not required to halt compilation but you can break a program
that violates this rule". IMO every such case *should* halt compilation
as a quality of implementation measure, but in this case it does not).
I don't think Gnulib should be thought of as part of the implementation
(thus, it should not have the right to use the implementation
namespace). It is distributed as part of the application, and not being
tested as part of the implementation, thus treating it as part of the
implementation invites trouble.
I understand that Gnulib is a bit special in that it reuses some
implementation code, but I don't think that factor is significant enough
here.
I thought I had an example where such choices lead to trouble in the
past, but I'm failing to find it now...
>> It should do so after all other includes, IMO.
>
> This is the kind of constraint that makes programming hard. Guess why
> PASCAL's restriction "first you have to define all types, then all
> variables - not intermixed" did not survive in modern programming
> languages.
I agree.
The C preprocessor also did not survive in modern programming languages,
exactly because it leads to constraints like these. And in the presence
of the preprocessor, "do not define stuff before including headers" is a
rule of thumb that makes programming easier.
>> Regarding the commit message: this doesn't really make the templates
>> more hygienic, I think (as templates can't leak the identifier anyway),
>> they just make them not break under the specific "unhygienic" context in
>> clisp itself.
>
> I took the notion of "hygienic" as meaning no collision with
> application-defined symbols from Scheme [1][2].
I understood, yes; though perhaps my view of the term "hygienic" is less
"symmetric" than it ought to be.
> Bruno
>
> [1] https://docs.scheme.org/guide/macros/
> [2] https://en.wikipedia.org/wiki/Hygienic_macro
--
Arsen Arsenović
signature.asc
Description: PGP signature
