On Tuesday, 28 November 2017 at 03:01:33 UTC, A Guy With an
Opinion wrote:
- Attributes. I had another post in the Learn forum about
attributes which was unfortunate. At first I was excited
because it seems like on the surface it would help me write
better code, but it gets a little tedious and tiresome to have
to remember to decorate code with them.
Then do it the C# way. There's choice.
I think the better decision would be to not have the errors
occur.
Hehe, I'm not against living in an idea world either.
- Immutable. I'm not sure I fully understand it. On the surface
it seemed like const but transitive. I tried having a method
return an immutable value, but when I used it in my unit test I
got some weird errors about objects not being able to return
immutable (I forget the exact error...apologies).
That's the point of static type system: if you make a mistake,
the code doesn't compile.
+- Unicode support is good. Although I think D's string type
should have probably been utf16 by default. Especially
considering the utf module states:
"UTF character support is restricted to '\u0000' <= character
<= '\U0010FFFF'."
Seems like the natural fit for me.
UTF-16 in inadequate for range '\u0000' <= character <=
'\U0010FFFF', though. UCS2 was adequate (for '\u0000' <=
character <= '\uFFFF'), but lost relevance. UTF-16 is only
backward compatibility for early adopters of unicode based on
UCS2.
Plus for the vast majority of use cases I am pretty guaranteed
a char = codepoint.
That way only end users will be able to catch bugs in production
system. It's not the best strategy, is it? Text is often
persistent data, how do you plan to fix a text handling bug when
corruption accumulated for years and spilled all over the place?
