A better language

Daniel Keep daniel.keep.lists at gmail.com
Sun Apr 16 10:49:58 PDT 2006


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

Yeah, /me wants that too.  You could *probably* fake it using some kind
of preprocessor and TypeInfo_* classes, but that's a bit iffy.

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

That's fine for single values, but what if you've got an expression?

# (SomeTemplate!(T,U)).type

looks a bit odd.

> // 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]

I can guarantee that you will never see the syntax `cast<int>`, since
that has the same problem as C++-style templates: they aren't context free.

Also, again, (some complex expression).cast(type) just seems a bit funky.

> 
> 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]

I'm ... not entirely sure what you're trying to do with this.  It looks
almost like extension methods, except with (basically) wildcard
matching.  Interesting idea, but I can't think of any cases where it'd
be useful.

You could probably emulate it with templates:

# template is_a(T : a)
# {
#     const bool is_a = true;
# }
#
# template is_a(T)
# {
#     const bool is_a = false;
# }]

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

Your sentence no parse correctly. (huh?)

Do you mean "make built-in types 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]

I don't like the name 'var', but I do think Walter should pick a new
keyword for inferred types (maybe 'infer'?).

Actually, from the docs, I get the impression it doesn't HAVE to be
'auto'; any storage class will do.  I still think there should be a
keyword whose only job is to say "normal storage class, figure out the
type for yourself".

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

C doesn't have templates.  I'm going to assume you meant "C++ syntax".
In which case, again, ain't going to happen (see `cast<int>`).

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

One of the biggest problems I had with C++ was all the casts.  I spent a
considerable amount of time pouring over C++ books, and I never did work
out what the hell those things do.

For my money, the cast we have is fine for the moment.  The only thing I
can think of that would be nice is some kind of decoupled conversion
like so:

# // In module scope
# void opCast(out DestType dest, SourceType src)
# {
#     // ...
# }

So that something like `T y = cast(T)x` would become `opCast(y,x)`.

But maybe that's just me. ^_^

> 
> 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]

Actually, what I'd *really* like to see is implicit 'new', but in the
Python sense:

# auto a = X(...); // same as...
# auto a = new X(...);

The rationale behind that is that classes and object factories are
suddenly interchangeable.

> 
> 9.
> Will be continued. :)

Dun, dun dunnnnnn...

> 
> Thank you for attention.
> 
> 

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/



More information about the Digitalmars-d mailing list