On Friday, 1 November 2019 at 10:39:42 UTC, Jacob Carlborg wrote:
On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster
wrote:
https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1
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.
