D

[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