Either I'm just too stupid, or D is lacking something

[Tom S]

Wolfgang Draxinger wrote:
> Don Clugston wrote:
> 
>> To follow several other languages...
>> identifier(str)
>>
>> creates an identifier called 'str', and is intended for dealing
>> with keyword conflicts. If str was allowed to be a compile-time
>> string literal, you could do practically *anything*. Easy
>> enough to implement. BUT...
> 
> Hmm, what about this, somebody might come up with:
> 
> template Foo(T, char[] name)
> {
>         sprintf(name, "foo_%s_1", name);
>         T identifier(name)(...){...};
> }

Rather something like this:

template Foo(T, char[] name) {
	T identifier("foo_" ~ name ~ "_1")(...){...};
}

since a template can't directly hold arbitrary code at the moment, but 
that's one of the intended usage patterns.



> I'd prefer to have string literals being treated by the compiler
> not directly as char[]. Depending on the context it may be
> treated like a char[] initializer or a lexical object.
> Additionally it might be usefull to add some string manipulation
> in the compiler, e.g. implementing the concatenation operator on
> the lexical scope (if not done already).

A char[] might be treated as a lexical object depending on the context ? 
Um.. this doesn't sound right. IMO it should be treated as a char[] and 
the lexical object's properties might be accessed by using some 
meta-library functions and/or special language features.


> template Foo(T, @name)
> {
>         T @"foo_" ~ name ~ "_1"(...);
> }
> 
> The '@' prefixing a template parameter would indicating, that it
> must be a compile time fixed string literal (this could also
> include const char[] literals on the module level). Within the
> template the '@' indicates, that the following string, which
> must be defined at compile time, is to be treated as a literal.

Sorry, but I don't feel like trading the '@' token just for compile-time 
strings to be more distinguishable.



> I understand, that it would make no large difference to implement
> this in form of char[] template parameter, but I prefer a
> different syntax to make it clear, that it means something
> different.

I don't understand why it should feel different. In my opinion, the 
language should be consistent on all its levels, be it metaprogramming, 
conditional compilation, standard high-level programming and low-level 
stuff. Ideally I'd like all D constructs to be available at compile-time 
e.g. in the way Nemerle does it. Actually there were some proposals 
about such functionality in the past.



--
Tomasz Stachowiak