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.

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

On Friday, 1 November 2019 at 10:39:42 UTC, Jacob Carlborg wrote:
> FYI, string is a built-in type.

string is immutable(char)[], as we all know. Syntactic sugar, not exactly a built in type but treating it like one is often valuable.

To follow on from this, I'll share my experience with doing exactly what SealabJaster is illustrating several times previously:

You also want to catch const(char)[] and just plain char[] for JSON serialisation purposes. So a template constraint that catches all those is what you want instead of just is( T == string ).

Dealing with wstring and dstring can be handled for bonus points... but eh, you only need to really worry about that if you are writing a library (or heavily use Phobos...).

On Friday, 1 November 2019 at 11:29:11 UTC, Ethan wrote:

> string is immutable(char)[], as we all know. Syntactic sugar, not exactly a built in type but treating it like one is often valuable.

It's an alias, but what it's aliased to is a built-in type.

--
/Jacob Carlborg

On Friday, 1 November 2019 at 12:50:09 UTC, Jacob Carlborg wrote:
> It's an alias, but what it's aliased to is a built-in type.

A *slice* of a built-in type *with qualifiers*.

The only way to simplify that description is to call it "syntactic sugar". "Built-in type" to describe the entire thing is only a half-truth.

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.

On Friday, 1 November 2019 at 11:29:11 UTC, Ethan wrote:
> You also want to catch const(char)[] and just plain char[] for JSON serialisation purposes. So a template constraint that catches all those is what you want instead of just is( T == string ).

I was definitely thinking of putting that in the first post, but thought it'd be better to leave it for later. Someone newer to D might not realise that a string is just a normal array/slice, instead of a special type (like in C++), so I didn't want to have to explain that yet.

I'd also need to explain the differences between const and immutable briefly.

I'm planning on going over it though in a post that goes over serialising arrays, which will likely be either the 4th or 5th one.

Though, there's always the possiblity I'm just worrying and overthinking too much about putting too much into each post. I'm trying to make things easy to digest, and since I'm not used to writing things like this, I don't have a great grasp on how a person newer to D would be able to follow it.

On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster wrote:
> ...
I've also made some changes to post #1 based on my last two comments on this thread.

I'd also like to clarify that the main purpose of this series is to demonstrate some of the thing of what D's metaprogramming can do, via the creation of the serialiser. The serialiser is just a by-product, so don't have the expectation that it's going to be amazingly robust. Though, maybe this is the wrong way to go about thing...

If anything, I just hope to not spread mis-information, or overly bad practices.

On Sunday, 3 November 2019 at 08:35:42 UTC, SealabJaster wrote:
> On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster wrote:
>> ...

Sorry, seems it cut out the first half of that reply.

New posts are out, and I don't want to spam Announce with new threads, so I'm just replying to this one.

#1.1 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1_1
#2 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser2

On Sunday, 3 November 2019 at 08:37:07 UTC, SealabJaster wrote:
> On Sunday, 3 November 2019 at 08:35:42 UTC, SealabJaster wrote:
>> On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster wrote:
>>> ...
>
> Sorry, seems it cut out the first half of that reply.
>
> New posts are out, and I don't want to spam Announce with new threads, so I'm just replying to this one.
>
> #1.1 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1_1
> #2 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser2

"This often seems to confuse people at first, especially those coming from other languages"

I think what's confusing people is that enum (short for ENUMERATION) is suddenly used like a constant/alias.

On Sunday, 3 November 2019 at 21:35:18 UTC, JN wrote:
> On Sunday, 3 November 2019 at 08:37:07 UTC, SealabJaster wrote:
>> On Sunday, 3 November 2019 at 08:35:42 UTC, SealabJaster wrote:
>>> On Friday, 1 November 2019 at 21:14:56 UTC, SealabJaster wrote:
>>>> ...
>>
>> Sorry, seems it cut out the first half of that reply.
>>
>> New posts are out, and I don't want to spam Announce with new threads, so I'm just replying to this one.
>>
>> #1.1 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1_1
>> #2 https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser2
>
> "This often seems to confuse people at first, especially those coming from other languages"
>
> I think what's confusing people is that enum (short for ENUMERATION) is suddenly used like a constant/alias.

I don't get why it confuses people.
In all languages I know (C, C++, Java, Pascal, etc..) they are used to associate a compile time symbols with some quantities, i.e. the definition of constants.
When an enumeration only consists of 1 value, then the enumeration is this value itself.