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