Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
sealabjaster at gmail.com
Fri Nov 1 21:09:26 UTC 2019
On Friday, 1 November 2019 at 10:39:42 UTC, Jacob Carlborg wrote:
> On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster
> FYI, string is a built-in type.
I feel it's more of a weird gray area. As Ethan said it's more
syntax sugar than a built-in type. However most code seems to
treat strings as built-in; the language's string literals are
useable with `string`; and they're common enough that they may as
well be defined as built-in.
So yea, even if I agree with Ethan that it's a "half-truth", I
feel there's likely less confusion if I decide to clump it in as
being built-in, so that'll be changed soon.
> Regarding exercise 2. I would be very careful with
> deserializing a single character from JSON. First, because JSON
> doesn't support single characters. Second, you'll run into
> issues with Unicode. For example, you would need to know the
> exact JSON content, not just the type, to specify the type that
> should be deserialized. Example:
> assert(json.deserialise!char() == '😀');
> The above will not work, because the type of '😀' is not `char`,
> it's `dchar`. The deserialization would need to throw an
> exception in this case, because '😀' won't fit in a `char`. It's
> much simpler to just not allow this use case.
> /Jacob Carlborg
To be honest, those are all good points, and I can't really think
of a counter argument.
Regarding `wchar` and `dchar` though (and their string versions),
I'm just not going to acknowledge they exist, since it's not a
hard requirement, and it's just more things I need to explain,
meaning more overhead on the reader.
More information about the Digitalmars-d-announce