First Impressions!

[Adam D. Ruppe]

On Tuesday, 28 November 2017 at 03:01:33 UTC, A Guy With an 
Opinion wrote:
> - Some of the errors from DMD are a little strange.

Yes, indeed, and many of them don't help much in finding the real 
source of your problem. I think improvements to dmd's error 
reporting would be the #1 productivity gain D could get right now.

> - ...however, where are all of the collections? No Queue? No 
> Stack? No HashTable?

I always say "meh" to that because any second year student can 
slap those together in... well, for a second year student, maybe 
a couple hours for the student, but after that you're looking at 
just a few minutes, especially leveraging D's built in arrays and 
associative arrays as your foundation.

Sure, they'd be nice to have, but it isn't a dealbreaker in the 
slightest.

Try turning Dictionary<string, string> into D's string[string], 
for example.

> Sometimes I want where it is physically on my file system to be 
> different from how I include it in other source files.

This is a common misconception, though one promoted by several of 
the tools: you don't actually need to match file system layout to 
modules.

OK, sure, D does require one module == one file. But the file 
name and location is not actually tied to the import name you use 
in code. They can be anything, you just need to pass the list of 
files to the compiler so it can parse them and figure out the 
names.

> - Attributes. I had another post in the Learn forum about 
> attributes which was unfortunate.

Yeah, of course, from my post there you know my basic opinion on 
them. I've written in more detail about them elsewhere and don't 
feel like it tonight, but I think they are a big failure right 
now.... but they could be fixed if we're willing to take a few 
steps (#0 improve the error messages, #1 add opposites to all of 
them, e.g. throws and @gc, #2, change the defaults via a single 
declaration at the module level, #3 omg revel in how useful they 
are)

> - Immutable. I'm not sure I fully understand it. On the surface 
> it seemed like const but transitive.

const is transitive too. So the difference is really that `const` 
means YOU won't change it, whereas `immutable` means NOBODY will 
change it.

What's important there is that to make something immutable, you 
need to prove to the compiler's satisfaction that nobody else can 
change it either.

const/immutable in D isn't as common as in its family of 
languages (C++ notably), but when you do get to use it - at least 
once you get to know it - it is useful.

> I was returning a value type, so I don't see why passing in 
> assert(object.errorCount == 0) would have triggered errors.

Was the object itself immutable? I suspect you wrote something 
like this:

immutable int errorCount() { return ...; }


But this is a curious syntax... the `immutable` there actually 
applies to the *object*, not the return value! It means you can 
call this method on an immutable object (in fact, it means you 
MUST call it on an immutable object. const is the middle ground 
that allows you to call it on either)


immutable(int) errorCount() { return ...; }

note the parens, is how you apply it to the return value. Yes, 
this is kinda weird, and style guides tend to suggest putting the 
qualifiers after the argument list for the `this` thing instead 
of before... but the language allows it before, so it trips up a 
LOT of people like this.

> The type string seems to be an immutable(char[]) which works 
> exactly the way I was expecting,

It is actually `immutable(char)[]`. The parens are important here 
- it applies to the contents of the array, but not the array 
itself here.

> +- Unicode support is good. Although I think D's string type 
> should have probably been utf16 by default. Especially 
> considering the utf module states:

Note that it has UTF-16 built in as well, with almost equal 
support. Put `w` at the end of a literal:

`"this literal is UTF-16"w` // notice the w after the "

and you get utf16. It considers that to be `wstring` instead of 
`string`, but it works basically the same.

If you are doing a lot of Windows API work, this is pretty useful!

> That was cool, and I'm not even sure if that is what they were 
> really meant to enable.

yes, indeed. plugging my book 
https://www.packtpub.com/application-development/d-cookbook i 
talk about much of this stuff in there