I love the idea of D language.
But I think it misses some usefult points.

1.
There is no compile-time reflection.
E.g. one could write:
[d]
class a
{
void f() {}
int i;
}

int a_methods = a.methods.length;
bool has_a_f = a.has_method(f);
int a_variables = a.variables.length;
bool has_a_i = a.has_variable(i);

// Or even
class b
{
void g();
}

type a_f_type = a.f.type;
foreach(auto b_f_type; b.methods)
if(a_f_type == b_f_type)
b.b_f_type(); // call b.g
[/d]

2.
Make all postfix:
[d]
// instead of
typeof(a) x = 1;

// write:
a.type x = 1;

// instead of
int a = cast(int)('a');

// write:
int a = 'a'.cast<int>;
// or if we have static_cast :)
int a = 'a'.static_cast<int>;
[/d]

3.
Extensible Metainformation:
E.g.
[d]
class a
{
meta
{
bool is_a = true;
}
}

meta // For all types
{
bool is_a = false;
}

a x;
int y;

static_assert(x.is_a == true);
static_assert(y.is_a == false);
[/d]

4.
Make built-in types likely to object types.

5.
'auto' keyword problem resolution.
auto x = new a(); // auto type, or auto destructor ?

E.g.:
[d]
auto a x = new a(); // destrutor
var x = new a(); // auto type
auto var x = new a(); // auto type + destructor
[/d]

6.
C syntax for templates.
It's so natural.

7.
More casts.
E.g.
static_cast
dynamic_cast
reinterpret_cast // make it safe, error if size of arguments is different
pointer_cast


8.
implicit 'new'.
E.g.
[d]
a x(...); // same as , a x = new a(...)
// same as , auto x = new a(...)

int[] q(1, 2, 3, 4, 5); // same as int[] q = new int[](1, 2, 3, 4, 5);
[/d]

9.
Will be continued. :)

Thank you for attention.

Welcome to newsgroups.

The name of a newsgroup generally states something about its subject matter.  To look the parts of this example:

digitalmars - the newsgroup is operated by Digital Mars.
D - the newsgroup is about D.
learn - the newsgroup is about learning.

So this is the Digital Mars newsgroup about learning D.  As such, putting just "D" as the subject line is useless.  A subject line must state something that distinguishes your post from other posts in the newsgroup.

Anyway....

N wrote:
<snip>
> 4.
> Make built-in types likely to object types.

Would you care to translate this into English?

> 5.
> 'auto' keyword problem resolution.
> auto x = new a(); // auto type, or auto destructor ?
<snip>

Been said many times already.

> 6.
> C syntax for templates.
> It's so natural.

C doesn't have templates.  What are you talking about?

> 7.
> More casts.
> E.g. static_cast
> dynamic_cast
> reinterpret_cast // make it safe, error if size of arguments is different
> pointer_cast
<snip>

Not sure how useful this complexity really would be....

Stewart.

Comments imbedded.

N wrote:
> I love the idea of D language.
> But I think it misses some usefult points.
> 
> 1.
> There is no compile-time reflection.

I agree with the usefulness of reflection (and have actually been secretly working on a proof-of-concept reflection system) but I don't see much value in your proposed mechanism:

> E.g. one could write:
> [d]
> class a
> {
> void f() {}
> int i;
> }
> 
> int a_methods = a.methods.length;

This is fine.

> bool has_a_f = a.has_method(f);

No.  For one thing, you can't pass 'f' as an orphaned symbol like this.  It creates a context-sensitive parsing nightmare.  Instead, my proposal would offer these:
# (a.method(`f`c) != null)
# a.method_exists(`f`c)

> int a_variables = a.variables.length;

This is fine, except I prefer to use the term Field for reflection, rather than Variable.

> bool has_a_i = a.has_variable(i);

Same as above.  Use one of:
# (a.field(`i`c) != null)
# a.field_exists(`i`c)

> 
> // Or even
> class b
> {
> void g();
> }
> 
> type a_f_type = a.f.type;
> foreach(auto b_f_type; b.methods)
> if(a_f_type == b_f_type)
> b.b_f_type(); // call b.g
> [/d]

# class Foo {
#   void g () {};
# }
#
# foreach (m; b.methods)       // note there's no need for auto here
#   if (typeof(a.f) == m.type)
#     m();

> 
> 2.
> Make all postfix:
> [d]
> // instead of
> typeof(a) x = 1;
> 
> // write:
> a.type x = 1;

The reason typeof(), typeid(), and is() are this way, as I understand it, is because they are compile time constructs.  (That and is() couldn't really work elegantly as a postfix.)

> // instead of
> int a = cast(int)('a');
> 
> // write:
> int a = 'a'.cast<int>;
> // or if we have static_cast :)
> int a = 'a'.static_cast<int>;
> [/d]

No <>'s please.  Parsing badness, and it just doesn't stand out quite as well to me as !() does.  Plus, cast is not a function to be templated, it is a language construct in the same family as typeof() et al.  We have little utility for static_cast, dynamic_cast, etc.  They just aren't as neccessary in D, so far as I have seen.

> 3.
> Extensible Metainformation:
> E.g.
> [d]
> class a
> {
> meta
> {
> bool is_a = true;
> }
> }
> 
> meta // For all types
> {
> bool is_a = false;
> }
> 
> a x;
> int y;
> 
> static_assert(x.is_a == true);
> static_assert(y.is_a == false);
> [/d]

That could be nifty.  I think I remember seeing one or two similar proposals -- might be worth searching the newsgroup and compiling it all together for discussion?

> 4.
> Make built-in types likely to object types.

Eh?  Explain?

> 5.
> 'auto' keyword problem resolution.
> auto x = new a(); // auto type, or auto destructor ?

In this case, auto type, because their is no type given.  Not that hard to distinguish.

> E.g.:
> [d]
> auto a x = new a(); // destrutor
> var x = new a(); // auto type
> auto var x = new a(); // auto type + destructor
> [/d]

I'm for it.

> 6.
> C syntax for templates.
> It's so natural.

First -- I think you mean C++ templates don't you?  Seeing as how C has none.  Second -- you are joking, yes?

# template afind (T : T[]) {
#   size_t afind (T needle, T[] haystack) {
#     foreach (i, x; haystack) {
#       static if (is(T : Object)) {
#         if (x is needle)
#           return i;
#       }
#       else {
#         if (x == needle)
#           return i;
#       }
#     }
#     return -1;
#   }
# }
#
# static int[] foo = [42, 314, 27, 82, 12, 9];
#
# size_t idx27 = afind(27, foo); // idx27 == 2

Of course this example assumes function template type inference is working -- which I think it would already for this example.  If it isn't working yet, then:

# size_t idx27 = afind!(int[])(27, foo);

Still not bad.  Or, if you want to get super generic:

# auto idx27 = afind!(typeof(foo))(27, foo);

Of course, usually somewhere this has already been done:

# alias afind!(int[]) afind;

Which makes the first invocation method work even without inference.  Yipee, as they say.

> 7.
> More casts.
> E.g. static_cast
> dynamic_cast
> reinterpret_cast // make it safe, error if size of arguments is different
> pointer_cast

No no no.  No use, just more typing.  Casting is all about subverting the type system for a moment anyhow.

> 
> 8.
> implicit 'new'.
> E.g.
> [d]
> a x(...); // same as , a x = new a(...)
> // same as , auto x = new a(...)

What do you do if you want a static opCall?  And is this on the heap or on the stack?  Too many questions, too little use, and what about on-the-fly instantiations?

-- Chris Nicholson-Sauls

Comments imbedded.

N wrote:
> I love the idea of D language.
> But I think it misses some usefult points.
> 
> 1.
> There is no compile-time reflection.

I agree with the usefulness of reflection (and have actually been secretly working on a
proof-of-concept reflection system) but I don't see much value in your proposed mechanism:

> E.g. one could write:
> [d]
> class a
> {
> void f() {}
> int i;
> }
> 
> int a_methods = a.methods.length;

This is fine.

> bool has_a_f = a.has_method(f);

No.  For one thing, you can't pass 'f' as an orphaned symbol like this.  It creates a
context-sensitive parsing nightmare.  Instead, my proposal would offer these:
# (a.method(`f`c) != null)
# a.method_exists(`f`c)

> int a_variables = a.variables.length;

This is fine, except I prefer to use the term Field for reflection, rather than Variable.

> bool has_a_i = a.has_variable(i);

Same as above.  Use one of:
# (a.field(`i`c) != null)
# a.field_exists(`i`c)

> 
> // Or even
> class b
> {
> void g();
> }
> 
> type a_f_type = a.f.type;
> foreach(auto b_f_type; b.methods)
> if(a_f_type == b_f_type)
> b.b_f_type(); // call b.g
> [/d]

# class Foo {
#   void g () {};
# }
#
# foreach (m; b.methods)       // note there's no need for auto here
#   if (typeof(a.f) == m.type)
#     m();

> 
> 2.
> Make all postfix:
> [d]
> // instead of
> typeof(a) x = 1;
> 
> // write:
> a.type x = 1;

The reason typeof(), typeid(), and is() are this way, as I understand it, is because they
are compile time constructs.  (That and is() couldn't really work elegantly as a postfix.)

> // instead of
> int a = cast(int)('a');
> 
> // write:
> int a = 'a'.cast<int>;
> // or if we have static_cast :)
> int a = 'a'.static_cast<int>;
> [/d]

No <>'s please.  Parsing badness, and it just doesn't stand out quite as well to me as !()
does.  Plus, cast is not a function to be templated, it is a language construct in the
same family as typeof() et al.  We have little utility for static_cast, dynamic_cast, etc.
 They just aren't as neccessary in D, so far as I have seen.

> 3.
> Extensible Metainformation:
> E.g.
> [d]
> class a
> {
> meta
> {
> bool is_a = true;
> }
> }
> 
> meta // For all types
> {
> bool is_a = false;
> }
> 
> a x;
> int y;
> 
> static_assert(x.is_a == true);
> static_assert(y.is_a == false);
> [/d]

That could be nifty.  I think I remember seeing one or two similar proposals -- might be
worth searching the newsgroup and compiling it all together for discussion?

> 4.
> Make built-in types likely to object types.

Eh?  Explain?

> 5.
> 'auto' keyword problem resolution.
> auto x = new a(); // auto type, or auto destructor ?

In this case, auto type, because their is no type given.  Not that hard to distinguish.

> E.g.:
> [d]
> auto a x = new a(); // destrutor
> var x = new a(); // auto type
> auto var x = new a(); // auto type + destructor
> [/d]

I'm for it.

> 6.
> C syntax for templates.
> It's so natural.

First -- I think you mean C++ templates don't you?  Seeing as how C has none.  Second --
you are joking, yes?

# template afind (T : T[]) {
#   size_t afind (T needle, T[] haystack) {
#     foreach (i, x; haystack) {
#       static if (is(T : Object)) {
#         if (x is needle)
#           return i;
#       }
#       else {
#         if (x == needle)
#           return i;
#       }
#     }
#     return -1;
#   }
# }
#
# static int[] foo = [42, 314, 27, 82, 12, 9];
#
# size_t idx27 = afind(27, foo); // idx27 == 2

Of course this example assumes function template type inference is working -- which I
think it would already for this example.  If it isn't working yet, then:

# size_t idx27 = afind!(int[])(27, foo);

Still not bad.  Or, if you want to get super generic:

# auto idx27 = afind!(typeof(foo))(27, foo);

Of course, usually somewhere this has already been done:

# alias afind!(int[]) afind;

Which makes the first invocation method work even without inference.  Yipee, as they say.

> 7.
> More casts.
> E.g. static_cast
> dynamic_cast
> reinterpret_cast // make it safe, error if size of arguments is different
> pointer_cast

No no no.  No use, just more typing.  Casting is all about subverting the type system for
a moment anyhow.

> 
> 8.
> implicit 'new'.
> E.g.
> [d]
> a x(...); // same as , a x = new a(...)
> // same as , auto x = new a(...)

What do you do if you want a static opCall?  And is this on the heap or on the stack?  Too
many questions, too little use, and what about on-the-fly instantiations?

-- Chris Nicholson-Sauls

Hello.  Welcome to newsgroups.

Newsreaders allow you to post a single message to two or more newsgroups
simultaneously.  This is called crossposting, and is the only
appropriate way to share a message across multiple newsgroups.

Please see

http://smjg.port5.com/faqs/usenet/xpost.html
http://www.cs.tut.fi/~jkorpela/usenet/xpost.html

and then, since you've multiposted this time, pick a 'group on which you
would like people to answer you.  Well, since your message started off as a followup to a post on digitalmars.D.learn, I'd suggest directing the followups there.

Stewart.