Blog series to teach and show off D's metaprogramming by creating a JSON serialiser

[SealabJaster]

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.