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
