First Impressions

[Jarrett Billingsley]

"Geoff Carlton" <gcarlton at iinet.net.au> wrote in message 
news:efhp1r$1r9s$1 at digitaldaemon.com...
> Hi,
> I'm a C++ user who's just tried D and I wanted to give my first
> impressions.  I can't really justify moving any of my codebase over to
> D, so I wrote a quick tool to parse a dictionary file and make a
> histogram - a bit like the wc demo in the dmd package.
>
> 1.)
> I was a bit underwhelmed by the syntax of char[].  I've used lua which
> also has strings,functions and maps as basic primitives, so going back
> to array notation seems a bit low level.  Also, char[][] is not the best
> start in the main() declaration.  Is it a 2D array, an array of
> arrays?  Then there is the char[][char[]].  What a mouthful for a simple
> map!
>
> Well, now I need to find elements.. I'd use std::string's find() here, but 
> the wc example has all array operations. Even isalpha is done as 'a', 'z' 
> comparisons on an indexed array. Back to low level C stuff.
>
> A simple alias of char[] to string would simplify the first glance code.
>   string x;    // yep, a string
>   main (string[]) // an array of strings
>   string[string] m; // map of string to string
>
> I believe single functions get pulled in as member functions?  e.g.
> find(string) can be used as string.find()?  If so, it means that all the
> string functionality can be added and then used naturally as member
> functions on this "string" (which is really just the plain old char[] in
> disguise).

They're more just syntactic sugar than member functions.  You can, in fact 
do this with any array type, e.g

void foo(int[] arr)
{
    ...
}

int[] x; x = [4, 5, 6, 7]; // bug in the new array literals ;)
x.foo();

> This is a small thing, but I think it would help in terms of the mindset
> of strings being a first class primitive, and clear up simple "hello
> world" examples at the same time.  Put simply, every modern language has
> a first class string primitive type, except D - at least in terms of
> nomenclature.

It does look nicer.  I suppose the counterargument would be that having an 
alias char[] string might not be portable -- what about wchar[] and dchar[]? 
Would they be wstring and dstring?  Or would we choose wchar[] or dchar[] to 
be string to be more forward-thinking (since languages like Java and C# 
already use UTF-16 as the default string type)?

I've never been too incredibly put off by char[], but of course other people 
have other opinions.

> 2.)
> I liked the more powerful for loop.  I'm curious is there any ability to 
> use delegates in the same way as lua does?  I was blown away the first 
> time I realised how simple it was for custom iteration in lua.  In short, 
> you write a function that returns a delegate (a closure?) that itself 
> returns arguments, terminating in nil.
>
>   e.g. for r in rooms_in_level(lvl) // custom function
>
> As lua can handle multiple return arguments, it can also do a key,value 
> sort of thing that D can do.  What a wonderful way of allowing any sort of 
> iteration.

Unfortunately the way Lua does "foreach" iteration is exactly the inverse of 
how D does it.  Lua gets an iterator and keeps calling it in the loop; D 
gives the loop (the entire body!) to the iterator function, which runs the 
loop.  So it's something like a "true" iterator as described in the Lua 
book:

level.each(function(r) print("Room: " .. r) end)

D does it this way I guess to make it easier to write iterators.  Since 
you're limited to one return value, it's simpler to make the iterator a 
callback and pass the indices into the foreach body than it is to make the 
iterator return multiple parameters through "out" parameters.  That, and 
it's easier to keep track of state with a callback iterator.  (I'm going 
through which to use in a Lua-like language that I'm designing too!)

> It beats pages of code in C++ to write an iterator that can go forwards, 
> or one that can go backwards (wow, the power of C++!).  C++09 still isn't 
> much of an improvement here, it only sugars the awful iterator syntax.

Weeeeeeeee!  C++

> 3.)
> From the newsgroups, it seems like 'auto' as local raii and 'auto' as
> automatic type deduction are still linked to the one keyword.  Well in 
> lua, 'local' is pretty intuitive for locally scoped variables.  Also 
> 'auto' will soon mean automatic type deduction in C++.  So those make 
> sense to me personally.  Looks like this has been discussed to death, but 
> thats my 2c.

I don't even wanna get into it ;)  _Technically_ speaking, auto isn't really 
"used" in type deduction; instead, the syntax is just <storage class> 
<identifier>, skipping the type.  Since the default storage class is auto, 
it looks like auto is being used to determine the type, but it also works 
like e.g.

static x = 5;

I think a better way to do it would be to have a special "stand-in" type, 
such as

var x = 5;
static var y = 20;
auto var f = new Foo(); // this will be RAII and automatically 
type-determined

> 4.)
> The D version of Scintilla and d-build was nice, very easy to use.
> Personally I would have preferred the default behaviour of dbuild to put 
> object files in an /obj subdirectory and the final exe in the original 
> directory dbuild is run from.
>
> This way, it could be run from a root directory, operate on a /src 
> subdirectory, and not clutter up the source with object files.  There is a 
> switch for that, of course, but I can't imagine when you would want object 
> files sitting in the same directory as the source.
>
> Well, as first impressions go, I was pleased by D, and am interested to 
> see how well it fares as time goes on.  Its just a shame that all the 
> tools/library/IDE is all in C++!
>
> Thanks,
> Geoff