Trying to use Mir ion, its a perfect example of the failure of D's attribute system

[H. S. Teoh]

On Thu, Jan 19, 2023 at 01:51:41AM +0000, A moo person via Digitalmars-d wrote:
[...]
> The entire library is annotated out the wazoo with @safe and @nogc and
> pure and inout. Its a serialization library so as you might imagine
> it's doing reflection on types, calling member functions to try and
> serialize stuff, things like that.

IMO, library code, esp. templated library code, should never have any
explicit attributes.  It should be left to compiler inference so that it
will work with user types of any kind, and attributes within the library
code itself should be enforced by appropriately attributed unittests.


> I have spent hours now adding attributes and casting attributes away.
> Writing @trusted wrapper types for std.algo ranges.

Something has gone deeply wrong when one has to resort to casts.  I'd
say file a bug against the library.


> Trying to decipher the vomit that dmd gives when one the types is not
> quite right.  All I want to do is serialize a list of structs from a
> range and be able to deserialize them back but I can't do that because
> I still have not gotten it working.

I'd just write serialization code myself. Thanks to D's introspection
abilities, this kind of code is not hard to write.  Use
std.traits.FieldNameTuple to get a list of fields in the struct, then
use std.conv.to to convert them to string.  On deserialization, do the
same thing except use std.conv.to to convert from the string to the
field type.  Probably some amount of customization will be needed if
your fields need special handling (e.g. string literals that should be
escaped in the serialized form / unescaped when you deserialize, etc.);
you can just use `static if (is(typeof(field) == MyCustomType))` to
handle those on a case-by-case basis.


> It's actually maddening, I have spent 2 days on this. What value are
> all these attributes adding? Because it's a useability nightmare.
> Every time I encounter a D library that tries to be clever with these
> annotations, it's just absolutely made things more complex and less
> useable. Same story every time I have ever tried to use them in my own
> code.

My policy is to let the compiler infer attributes as much as possible,
and only write them manually when I really, really, *really* need to.
Then use attributed unittests to make sure the compiler doesn't suddenly
change its mind about how something is attributed.

In general, I think we should move in the direction of expanding
attribute inference as far as possible.  Nobody wants to deal with
attribute soup; it should be the compiler's job to automate this tedium
as much as possible and only leave it up to the human when there's no
other way around it.


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce