Firstly, I had no idea where suggestions should go, and I saw a
few others here and thus here I am.
I was writing some code that depended heavily on my own eponymous
templates, and decided to change the names of some of them to
make them more self-documenting. However, after changing the
name, I encountered a long stream of unintelligible errors (to
me, I haven't been using D for a long time) about template
instances.
So, my idea is that the 'this' keyword could be used in templates
as a shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some
templates, as well as reducing maintenance.

Firstly, I had no idea where suggestions should go, and I saw a few
others here and thus here I am.

AFAIK this is as good a place as any other.

I was writing some code that depended heavily on my own eponymous
templates, and decided to change the names of some of them to make
them more self-documenting. However, after changing the name, I
encountered a long stream of unintelligible errors (to me, I haven't
been using D for a long time) about template instances.
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}

[...]
+1. I like this idea. In fact, I've thought about proposing it before.
:-) I don't like the idea of having to repeatedly retype the template
name. I mean, the compiler already implicitly translates:
int myfunc(T)(T args) { ... }
to:
template myfunc(T) {
int myfunc(T args) { ... }
}
and nowadays pretty much *nobody* writes it the second way anymore.
Having to repeatedly type the same identifiers is one of the things that
puts me off so much about Java. Especially with its proliferation of
overly long identifiers (and their respective *Wrappers thereof).
T
--
The richest man is not he who has the most, but he who needs the least.

So, my idea is that the 'this' keyword could be used in
templates as a shortcut for eponymous templates, allowing code
like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}

+1 for This
"bearophile" wrote in message news:bcqvpvgjswwdgsfxsars forum.dlang.org...
Reid Levenick:

So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}

+1 for This
"bearophile" wrote in message news:bcqvpvgjswwdgsfxsars forum.dlang.org...
Reid Levenick:

So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}

Walter and I discussed this idea a while ago. It's a good one.
To ease into things eponymous templates should work both ways for a while.
We should define a little protocol for ideas that Walter approves but
has higher-priority tasks to work on. Like DIPs that he gives the seal
of approval to, so people know they can work on them.
Andrei

Firstly, I had no idea where suggestions should go, and I saw a
few others here and thus here I am.
I was writing some code that depended heavily on my own
eponymous templates, and decided to change the names of some of
them to make them more self-documenting. However, after
changing the name, I encountered a long stream of
unintelligible errors (to me, I haven't been using D for a long
time) about template instances.
So, my idea is that the 'this' keyword could be used in
templates as a shortcut for eponymous templates, allowing code
like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some
templates, as well as reducing maintenance.

I like the idea. To get rid of any confusion with keywords,
name-mangling, or classes, I suggest having "this" being
syntactic sugar for the name of the template.
NMS

Firstly, I had no idea where suggestions should go, and I saw a few
others here and thus here I am.
I was writing some code that depended heavily on my own eponymous
templates, and decided to change the names of some of them to make them
more self-documenting. However, after changing the name, I encountered a
long stream of unintelligible errors (to me, I haven't been using D for
a long time) about template instances.
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some templates, as
well as reducing maintenance.

Firstly, I had no idea where suggestions should go, and I saw a few others
here and thus here I am.
I was writing some code that depended heavily on my own eponymous templates,
and decided to change the names of some of them to make them more
self-documenting. However, after changing the name, I encountered a long
stream of unintelligible errors (to me, I haven't been using D for a long
time) about template instances.
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some templates, as well
as reducing maintenance.

Firstly, I had no idea where suggestions should go, and I saw a few
others here and thus here I am.
I was writing some code that depended heavily on my own eponymous
templates, and decided to change the names of some of them to make them
more self-documenting. However, after changing the name, I encountered a
long stream of unintelligible errors (to me, I haven't been using D for
a long time) about template instances.
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some templates, as
well as reducing maintenance.

This has been suggested about 200 times...
As already mentioned, use of 'this' conflicts with 'alias this'.
I also think there are problems with local templates.
class S
{
void foo()
{
template XX(int n) {
alias this this; // !! first 'this' is S, second is XX
}
XX!(7) q;
}
}
Another suggestion that was made in the past was 'return'. I suspect
that doesn't work, either, because for example typeof(return) already
has a meaning.

Firstly, I had no idea where suggestions should go, and I saw a few
others here and thus here I am.
I was writing some code that depended heavily on my own eponymous
templates, and decided to change the names of some of them to make them
more self-documenting. However, after changing the name, I encountered a
long stream of unintelligible errors (to me, I haven't been using D for
a long time) about template instances.
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some templates, as
well as reducing maintenance.

The general idea is useful, but there are issues.
'this' is the wrong keyword for the job. A class or struct instance is
very different from a template instance and the proposed usage would
clash with existing and useful ones. (assuming that it would work for
symbol lookups in addition to declarations)
'template' or maybe 'scope' would be superior choices.
Furthermore, what happens if such a 'this'-template is mixed in into
another template?

The general idea is useful, but there are issues.
'this' is the wrong keyword for the job. A class or struct instance is
very different from a template instance and the proposed usage would
clash with existing and useful ones. (assuming that it would work for
symbol lookups in addition to declarations)
'template' or maybe 'scope' would be superior choices.

I think static is underused keyword, maybe it should have a dual meaning
here.
In all seriousness, I'm not sure template is right either. Scope sounds
like a very bad choice to me.
Are there any eponymous examples where the name of the template is the
first token? If so that would clash with declaring a new template.
I would find this weird:
template X(T)
{
alias T template;
template t {
...
}
}
It looks like you are using template as an alias to T, but the second
'template' inside is using it for creating a new template.
Also, consider this:
template X(T)
{
class template {
static typeof(this) create() { return new typeof(this);}
}
}
I don't think you could realistically use any keyword instead of
typeof(this), I really think the best solution is what we have, or use a
new keyword.
Another option is to do something like:
eponymous template X(T) // changed from Y(T)
{
class Y { } // oops forgot to change this to X!
}
Error: template X did not declare eponymous symbol
At least changes would be loud errors.
-Steve

The general idea is useful, but there are issues.
'this' is the wrong keyword for the job. A class or struct instance is
very different from a template instance and the proposed usage would
clash with existing and useful ones. (assuming that it would work for
symbol lookups in addition to declarations)
'template' or maybe 'scope' would be superior choices.

I think static is underused keyword, maybe it should have a dual meaning
here.
In all seriousness, I'm not sure template is right either.

It is better than 'this', because it is unambiguous. I didn't say it was
right. ;)

Scope sounds like a very bad choice to me.

Why? Templates are parameterized scopes.

Are there any eponymous examples where the name of the template is the
first token?

No, there isn't even a declaration that starts with the identifier it
defines.

If so that would clash with declaring a new template.
I would find this weird:
template X(T)
{
alias T template;
template t {
...
}
}
symbol
It looks like you are using template as an alias to T, but the second
'template' inside is using it for creating a new template.
Also, consider this:
template X(T)
{
class template {
static typeof(this) create() { return new typeof(this);}
}
}
I don't think you could realistically use any keyword instead of
typeof(this), I really think the best solution is what we have,

Well, there is always the possibility of just doing it like this:
template X(T) {
enum X = result; // single line in template body that needs to
change if there is a name change
static if(is(T==int)) enum result = foo;
else static if(is(T==real)) enum result = bar;
else static if(is(T==double)) enum result = baz;
else enum result = qux;
}
Unless someone can come up with a super-elegant way to resolve all the
issues raised, I don't actually think that the proposal adds enough value.

The general idea is useful, but there are issues.
'this' is the wrong keyword for the job. A class or struct instance is
very different from a template instance and the proposed usage would
clash with existing and useful ones. (assuming that it would work for
symbol lookups in addition to declarations) 'template' or maybe
'scope' would be superior choices.

What about "this template"? Clear, self-documenting, and unambiguous.
template X(T) {
alias const(T) this template;
}
T
--
One disk to rule them all, One disk to find them. One disk to bring them all
and in the darkness grind them. In the Land of Redmond where the shadows lie.
-- The Silicon Valley Tarot