Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
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.
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
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.
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
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.
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
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
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
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...).
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
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
DLang Tour Now Supports Korean
BOSKorea has a few Korean programmers who had never used D before joining the company. Now future hires can take the DLang Tour in Korean. Thanks to Mathias Lang for initiating the translation effort. https://tour.dlang.org/tour/en/welcome/languages
