It would be nice to be able to have a precompilation step that produces a d output file that is the "mixed down" version with all the string mixins computed. This would allow one to look at the files, allow better code analysis/error messages, and intellisense and other things to be useful.

A simple compiler switch would do the trick to enable such a feature. *.dc files could be generated, or whatever, for each d file if it uses string mixins(I suppose template mixins could also be reduced).

Am 31.07.2013 14:09, schrieb JS:
> It would be nice to be able to have a precompilation step that
> produces a d output file that is the "mixed down" version with
> all the string mixins computed. This would allow one to look at
> the files, allow better code analysis/error messages, and
> intellisense and other things to be useful.
>
> A simple compiler switch would do the trick to enable such a
> feature. *.dc files could be generated, or whatever, for each d
> file if it uses string mixins(I suppose template mixins could
> also be reduced).

what about something that catches mixin results into a static compiletime strings

template GenStruct(string Name, string M1)
{
    const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
}

which generates:

struct Foo { int bar; }

catch_generated_output(my_mixin_output)
{
  mixin(GenStruct!("Foo", "bar"));
}

pragma(msg, my_mixin_output);

prints:

struct Foo { int bar; }

Am 31.07.2013 14:23, schrieb dennis luehring:
> Am 31.07.2013 14:09, schrieb JS:
>> It would be nice to be able to have a precompilation step that
>> produces a d output file that is the "mixed down" version with
>> all the string mixins computed. This would allow one to look at
>> the files, allow better code analysis/error messages, and
>> intellisense and other things to be useful.
>>
>> A simple compiler switch would do the trick to enable such a
>> feature. *.dc files could be generated, or whatever, for each d
>> file if it uses string mixins(I suppose template mixins could
>> also be reduced).
>
> what about something that catches mixin results into a static
> compiletime strings
>
> template GenStruct(string Name, string M1)
> {
>       const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
> }
>
> which generates:
>
> struct Foo { int bar; }
>
> catch_generated_output(my_mixin_output)
> {
>     mixin(GenStruct!("Foo", "bar"));
> }

or as an optional parameter for mixin(GenStruct!("Foo", "bar"), my_mixin_output)?

On Wednesday, 31 July 2013 at 12:23:42 UTC, dennis luehring wrote:
> Am 31.07.2013 14:09, schrieb JS:
>> It would be nice to be able to have a precompilation step that
>> produces a d output file that is the "mixed down" version with
>> all the string mixins computed. This would allow one to look at
>> the files, allow better code analysis/error messages, and
>> intellisense and other things to be useful.
>>
>> A simple compiler switch would do the trick to enable such a
>> feature. *.dc files could be generated, or whatever, for each d
>> file if it uses string mixins(I suppose template mixins could
>> also be reduced).
>
> what about something that catches mixin results into a static compiletime strings
>
> template GenStruct(string Name, string M1)
> {
>     const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
> }
>
> which generates:
>
> struct Foo { int bar; }
>
> catch_generated_output(my_mixin_output)
> {
>   mixin(GenStruct!("Foo", "bar"));
> }
>
> pragma(msg, my_mixin_output);
>
> prints:
>
> struct Foo { int bar; }


I already do that... When you do that with nested templates it creates a huge mess... also errors are useless... as the point to the mixin string.

Simple examples are easy to come up with but don't demonstrate how useless they can be.

Am 31.07.2013 14:35, schrieb JS:
> On Wednesday, 31 July 2013 at 12:23:42 UTC, dennis luehring wrote:
>> Am 31.07.2013 14:09, schrieb JS:
>>> It would be nice to be able to have a precompilation step that
>>> produces a d output file that is the "mixed down" version with
>>> all the string mixins computed. This would allow one to look at
>>> the files, allow better code analysis/error messages, and
>>> intellisense and other things to be useful.
>>>
>>> A simple compiler switch would do the trick to enable such a
>>> feature. *.dc files could be generated, or whatever, for each d
>>> file if it uses string mixins(I suppose template mixins could
>>> also be reduced).
>>
>> what about something that catches mixin results into a static
>> compiletime strings
>>
>> template GenStruct(string Name, string M1)
>> {
>>     const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~
>> "; }";
>> }
>>
>> which generates:
>>
>> struct Foo { int bar; }
>>
>> catch_generated_output(my_mixin_output)
>> {
>>   mixin(GenStruct!("Foo", "bar"));
>> }
>>
>> pragma(msg, my_mixin_output);
>>
>> prints:
>>
>> struct Foo { int bar; }
>
>
> I already do that...

it was just a proposal to have something between all (on commandline) and areas of the source

>When you do that with nested templates it
> creates a huge mess... also errors are useless... as the point to
> the mixin string.

and what does a complete output help then better?

On Wednesday, 31 July 2013 at 13:19:46 UTC, dennis luehring wrote:
> Am 31.07.2013 14:35, schrieb JS:
>> On Wednesday, 31 July 2013 at 12:23:42 UTC, dennis luehring wrote:
>>> Am 31.07.2013 14:09, schrieb JS:
>>>> It would be nice to be able to have a precompilation step that
>>>> produces a d output file that is the "mixed down" version with
>>>> all the string mixins computed. This would allow one to look at
>>>> the files, allow better code analysis/error messages, and
>>>> intellisense and other things to be useful.
>>>>
>>>> A simple compiler switch would do the trick to enable such a
>>>> feature. *.dc files could be generated, or whatever, for each d
>>>> file if it uses string mixins(I suppose template mixins could
>>>> also be reduced).
>>>
>>> what about something that catches mixin results into a static
>>> compiletime strings
>>>
>>> template GenStruct(string Name, string M1)
>>> {
>>>    const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~
>>> "; }";
>>> }
>>>
>>> which generates:
>>>
>>> struct Foo { int bar; }
>>>
>>> catch_generated_output(my_mixin_output)
>>> {
>>>  mixin(GenStruct!("Foo", "bar"));
>>> }
>>>
>>> pragma(msg, my_mixin_output);
>>>
>>> prints:
>>>
>>> struct Foo { int bar; }
>>
>>
>> I already do that...
>
> it was just a proposal to have something between all (on commandline) and areas of the source
>
> >When you do that with nested templates it
> > creates a huge mess... also errors are useless... as the
> point to
> > the mixin string.
>
> and what does a complete output help then better?

Because it won't double up on pragmas.

If you nest templates using your method, which I do, then you will get multiple pragma outputs but you'll always only have one string mixin.

the processed output will be actual D code, not a bunch of pragma messages, which could be anything... even invalid D code if they are formatted that way.

On Wednesday, 31 July 2013 at 13:25:45 UTC, JS wrote:
> On Wednesday, 31 July 2013 at 13:19:46 UTC, dennis luehring
>> >When you do that with nested templates it
>> > creates a huge mess... also errors are useless... as the
>> point to
>> > the mixin string.

There is one idiom for debugging string mixin mess:
098: // pragma(msg, "mixin_id:");
099: // pragma(msg, generated_code);
100: #line 1 "mixin_id"
101: mixin(generated_code)
102: #line 103 __FILE__

Not very convenient, but enough to get the job done.

Sonke had nice idea to improve compiler by storing mixin id as part of filename an preserving line numbers as-is. Somewhat breaking change though.

On Wednesday, 31 July 2013 at 13:37:58 UTC, Dicebot wrote:
> On Wednesday, 31 July 2013 at 13:25:45 UTC, JS wrote:
>> On Wednesday, 31 July 2013 at 13:19:46 UTC, dennis luehring
>>> >When you do that with nested templates it
>>> > creates a huge mess... also errors are useless... as the
>>> point to
>>> > the mixin string.
>
> There is one idiom for debugging string mixin mess:
> 098: // pragma(msg, "mixin_id:");
> 099: // pragma(msg, generated_code);
> 100: #line 1 "mixin_id"
> 101: mixin(generated_code)
> 102: #line 103 __FILE__
>
> Not very convenient, but enough to get the job done.
>
> Sonke had nice idea to improve compiler by storing mixin id as part of filename an preserving line numbers as-is. Somewhat breaking change though.

I already have a method where I use level to store the nesting level, somewhat inconvenient but it allows me to not show any nested calls, just the top most template call...

But it doesn't help with intellisense, which thinks the structs/classes are empty because I generate everything with mixins(or almost everything at this point)... and is still hard to read. I'd rather be able to look at a complete D source to see if anything is out of place then look at a build console output(which may contain other information and doesn't show much context for the mixin).