On Friday, 20 January 2023 at 19:18:23 UTC, Walter Bright wrote:
> In general, yes, moving towards attribute inference for ordinary functions rather than just templates is where we want to go.
>
> The reason it isn't done currently is because it makes .di declarations incompatible with the .d definitions.

.di needs to become a lot better before impacting some kind of decision:

1. It needs a specific coding style to improve its output, such as writing your import inside the functions itself, though it should only expose what is really needed. Read that as classes, interfaces, types. Unless the user don't public import constants or functions, there's no reason to it be included in output, unless present in a template.

2. It could be used to do CTFE caching. As far as I understand, it is not possible to do that right now. But it would make a huge gain to the D community and would make it a lot more appealing.

3. The inference could be passed to the .di files at generation time. That would mean:
```d
int add(int a, int b){return a+b;}
```
Could easily be output to the .di as:
```d
@safe pure nothrow @nogc int add(int a, int b);
```

This could even save time in the .di usage as it would save the work of needing to do any kind of inference in library code.

This is things I could think out of the box. I would say that we are lacking tooling support for .di too. I don't think dub integrates nicely with .di files, which were one of the reasons I'm not using it.

Plus, as Adam said many times, the .di generation is pretty raw right now, so, there's a lot of handwork to maintain one of those, I believe that solving those items could be improved.


Plus, we could create an attribute specifically used for templates which are meant to only be instantiated once, such as `@noexport`, which would mean that in the .di output, it would not need to keep the template itself. This is useful for not exporting code that was only done for inline ctfe'd.

On 21/01/2023 10:23 AM, Hipreme wrote:
> This is things I could think out of the box. I would say that we are lacking tooling support for .di too. I don't think dub integrates nicely with .di files, which were one of the reasons I'm not using it.

Dub doesn't abstract the .di generator. However it is very easy to pass in the flags in to make it do what you want. This is not a limiting factor.

Fact is, the .di generator doesn't produce usable D code, nor does it produce it in a way that -I can use.

It is useless in its current state and is a major issue that will need to be solved once DLL's work properly in dmd.

On Friday, 20 January 2023 at 21:33:11 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Fact is, the .di generator doesn't produce usable D code, nor does it produce it in a way that -I can use.
>
> It is useless in its current state and is a major issue that will need to be solved once DLL's work properly in dmd.

It doesn't even work for static libraries? That's concerning, if true.

On Friday, 20 January 2023 at 00:31:54 UTC, H. S. Teoh wrote:
> I'd just write serialization code myself.

Yep this is what I am doing now. Not the first time I have written a serializer in D using traits(allMembers) but its old and not well maintained. I was attracted to Mir because it can do text and binary. I was hoping to use text for development and switch to binary for release. But I will just write my own, it might be a little more work but it's not so bad if I don't try to handle indirection and allocation. Just structs, getter/setters that return structs, and input/output ranges for iterables.

On 21/01/2023 11:03 AM, Paul Backus wrote:
> On Friday, 20 January 2023 at 21:33:11 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Fact is, the .di generator doesn't produce usable D code, nor does it produce it in a way that -I can use.
>>
>> It is useless in its current state and is a major issue that will need to be solved once DLL's work properly in dmd.
> 
> It doesn't even work for static libraries? That's concerning, if true.

The only thing that differentiates static from shared libraries is export. That was never an issue when I last tried it.

On Friday, 20 January 2023 at 19:18:23 UTC, Walter Bright wrote:
> In general, yes, moving towards attribute inference for ordinary functions rather than just templates is where we want to go.
>
> The reason it isn't done currently is because it makes .di declarations incompatible with the .d definitions.

Do people even use .di's?

On 1/20/23 15:53, Steven Schveighoffer wrote:
> On 1/20/23 8:08 AM, Quirin Schroll wrote:
> 
>>
>> If D added 1 fixed-name attribute variable per attribute (cf. `inout`), they could be spelled `@safety`, `purity`, `@gcness`, and `throwiness`.
>>
>> ```d
>> void callInSequence(
>>      void delegate() @safety purity @gcness throwiness[] dgs
>> ) @safety purity @gcness throwiness
>> {
>>      foreach (dg; dgs) dg();
>> }
>> ```
> 
> My proposal was basically to have a `@called` attribute that indicates the function delegate may be called inside the function, meaning the attributes of the call should reflect the attributes of the parameter.

The issue with that is that it does not generalize/compose. E.g., you can't write a non-templated function that composes two delegates while preserving attributes.

On Friday, 20 January 2023 at 14:53:49 UTC, Steven Schveighoffer wrote:
> My proposal was basically to have a `@called` attribute that indicates the function delegate may be called inside the function, meaning the attributes of the call should reflect the attributes of the parameter.
>

I really hate that the proposal to the problem of too many attributes in the language is "hey lets add another attribute"... like really?

On Thursday, 19 January 2023 at 04:06:27 UTC, A moo person wrote:
> struct PageSerial {
> 	// this is just some GUI element
> 	// the contents of this gui element is what I am trying to ser/deser
> 	private Grid g;
>
> 	@serdeKeys("blocks")
> 	@serdeIgnoreIn
> 	//@serdeLikeList
> 	auto blocks_out() @property @trusted const {
> 		// Had to put @trusted because the mir function to ser/deser is @safe
> 		// Had to put const because the mir function decides to cast my type to const when working with it?? no idea why
>
> 		import std.algorithm : filter, map;
> 		import std.range : ElementType;
> 		// have to cast away the const
> 		auto t = cast(PageSerial*)(&this);
> 		auto r =
> 			(t.g).contents.children()[]
> 			.filter!(c => (cast(GridBlock)c !is null))()
> 			.map!(c => GridBlockSerial(cast(GridBlock)c))();
> 		static assert(is(ElementType!(typeof(r)) == GridBlockSerial));

Not every type can be serialized, normally you serialize a DTO - a type designed for serialization and holds primitive or simple data, then it will be compatible with attributes.