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

Wolfgang Draxinger wrote:
> Don Clugston wrote:
>> The problem is, it would be practically impossible for an IDE
>> to deal with. (although, maybe that's true already).
> 
> Hmm, it wouldn't bee too complicated for an IDE to follow. D is
> dread easy to parse compared to C or C++ (what the DMD frontend
> proofes). An IDE using a D frontend would have no problems.

Keep in mind that the IDE's job is already somewhat more difficult than that of the compiler: it's much more important for the IDE to do something sane with invalid code than for the compiler to be able to do so.

For the compiler dealing with invalid code is mostly useful in producing useful diagnostics, but for the IDE it can be pretty important to parse incomplete code.

You don't typically compile a source file known to be invalid, but the IDE will have to deal with that all the time while you're typing it up: most of the time while you're typing it the code is likely to be invalid.

On Fri, 28 Jul 2006 15:27:11 +0200, Wolfgang Draxinger wrote:


> Of course D's metaprogramming is already way ahead of C++, but the lack of ability to introduce new identifiers by templates/mixins is an itching spot to me.

Agreed. The fact that mixins can only be used to generate declarations is a huge restriction. However I'm sure that Walter can devise a similarly safe way for mixins in the future to generate other types of D code, such as identifiers, blocks and statements. So until then mixins have limited utility.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Oskar Linde wrote:
> Oskar Linde skrev:
>> Wolfgang Draxinger skrev:
>>> Oskar Linde wrote:
>>>
>>>> It is a minor change, but would break existing code, so getting
>>>> it before 1.0 would be preferred.
>>>
>>> Could you give me an example of breakage? I don't see a reason
>>> (yet), why that would break something. I'd have said, that my
>>> suggestion is a superset of the old behaviour and backwards
>>> compatible, but seem's I was wrong.
>>
>> Currently, when a template contains several functions, they are not implicit template properties and must be called as func!().func(...). If the proposed change was introduced, they would be required to be called as func!()(...). Example:
> 
> Another proposal that I made before in conjunction with the above is to make implicit template properties explicit via the /this/ keyword. It would work analogous to how /this/ is used to denote class constructors.
> 
> template myfunc(T) {
>     T this() {...}
>     T this(int x) {...}
>     T this(double x) {...}
> }
> 
> and:
> 
> template IsSomethingOrWhatever(T) {
>     const this = ...;
> }
> 
> The advantages would be that implicit template properties would become explicit. It would in many cases save some typing and leave only one instead of two places to update when a template is renamed. The somewhat dubious rule of special handling when the template and template member name are the same could be removed.
> 
> One could also imagine private template members in conjunction with implicit template properties. Something that isn't possible today:
> 
> template myfync(T) {
>     private alias Something!(T) SomeType;
> 
>     SomeType this() { ... }
>     SomeType this(int x) { ... }
>     SomeType this(double x) { ... }
> }
> 
> which would both improve readability and save typing. Not only for the case with several polymorphic template functions:
> 
> template foo(T1,T2) {
>     private alias ALongExpression!(Involving!(T1).and!(T2)) RetType;
> 
>     RetType this(T1 a, T2 b) {
>         RetType ret;
>         ...
>         return ret;
>     }
> }
> 
> With todays templates, the above becomes less readable.
> 
> /this/ would be shadowed by locally defined classes, just like /this/ currently gets shadowed by inner classes.
> 
> /Oskar
> 

Seems like a nice idea, although I would prefer a keyword other than "this", even if a new one, like "thisalias" or something. I'd like to think of "this" as always referring to some kind of runtime instance.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Oskar Linde wrote:
[snip]
>> template IsSomethingOrWhatever(T) {
>>     const this = ...;
>> }
[snip]
> 
> Seems like a nice idea, although I would prefer a keyword other than "this", even if a new one, like "thisalias" or something. I'd like to think of "this" as always referring to some kind of runtime instance.
> 

It matches the current use of /this/ as class constructor and destructor:

class T {
	this() {...}
	~this() {...}
}

/Oskar