On 8/21/20 5:56 PM, Adam D. Ruppe wrote:
> On Friday, 21 August 2020 at 21:42:21 UTC, Steven Schveighoffer wrote:
>> While not necessarily a "bug", it's not very useful.
> 
> Maybe not in this case, but it is perfectly accurate for cases like:
> 
> mixin(q{
>     some code here
> });
> 
> Where it will actually line back up to the original file's line number perfectly.
> 
> 

Who does that though? Why not just write "some code here" right in the file? (I know that the string interpolation DIP might make this more likely)

And honestly, if it says the source is "mixin-50, line 1", I think people will get it.

Whereas, if the code is like:

mixin(generateTheMixin());

and it says the line is 67, and line 67 has nothing to do with the mixin source or the location it's mixed in, but instead, you need to subtract the line number of mixing in from 67 to get the *real* line number, I think the utility is really gone at that point.

-Steve

On Friday, 21 August 2020 at 22:12:48 UTC, Steven Schveighoffer wrote:
> Who does that though?

An incompetent coder:

http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L5713
http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L5943
http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L6018
http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L6058

I actually do kinda a lot. It is kinda useful for adding declarations with mixed in names (the whole declaration must be mixed in even if the only unique part is the name), or the first instance there is to version out features where the compiler's parser worked (I maintain compatibility with 2+ year old compilers too and if the parser changes, version alone will not work).

> And honestly, if it says the source is "mixin-50, line 1", I think people will get it.

I could probably live with that too, but the status quo is pretty useful as-is.

On 8/21/20 6:34 PM, Adam D. Ruppe wrote:
> On Friday, 21 August 2020 at 22:12:48 UTC, Steven Schveighoffer wrote:
>> And honestly, if it says the source is "mixin-50, line 1", I think people will get it.
> 
> I could probably live with that too, but the status quo is pretty useful as-is.

I wonder if the compiler could detect when you are using a string literal vs. a generated or imported string, and change the behavior accordingly.

-Steve

On Saturday, 22 August 2020 at 03:43:10 UTC, Steven Schveighoffer wrote:
> On 8/21/20 6:34 PM, Adam D. Ruppe wrote:
>> On Friday, 21 August 2020 at 22:12:48 UTC, Steven Schveighoffer wrote:
>>> And honestly, if it says the source is "mixin-50, line 1", I think people will get it.
>> 
>> I could probably live with that too, but the status quo is pretty useful as-is.
>
> I wonder if the compiler could detect when you are using a string literal vs. a generated or imported string, and change the behavior accordingly.

As far as I understand behavior of this is that mixin() changes __FILE__ to point to the location of this mixin. But import expression doesn't do so. So if import("file") could change __FILE__ to "file" and __LINE__ to 1 internally that will make sense IMHO.
I mean something like this:
                //__FILE__='test', __LINE__=1
mixin(          //__FILE__='test-mixin-2', __LINE__=2
                //__FILE__='test-mixin-2', __LINE__=3
import("file")  //__FILE__='file', __LINE__=1           - only inside import()  !!!
                //__FILE__='test-mixin-2', __LINE__=5
)
                //__FILE__='test', __LINE__=7

On Friday, 21 August 2020 at 22:34:49 UTC, Adam D. Ruppe wrote:
> On Friday, 21 August 2020 at 22:12:48 UTC, Steven Schveighoffer wrote:
>> Who does that though?
>
> An incompetent coder:
>
> http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L5713
> http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L5943
> http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L6018
> http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L6058

Even this approach can lead to unclear result if you move 'q{...}' outside of mixin:
=========================
void test(string file = __FILE__, size_t line = __LINE__)
{
    writefln("file: '%s', line: '%s'", file, line);
}

int main(string[] args)
{
    enum code = q{
        // empty line 15
        // empty line 16
        // empty line 17
        // empty line 18
        // empty line 19
        test(); // line 20
    };

    test();        // line 23
    mixin(code);   // line 24
    test();        // line 25
    return 0;      // line 26
}                  // line 27
===========================

The output is the following:
file: 'test.d', line: '23'
file: 'test.d-mixin-24', line: '30'
file: 'test.d', line: '25'

Note that there is no line 30!

On Sunday, 23 August 2020 at 12:50:36 UTC, Andrey Zherikov wrote:
> Even this approach can lead to unclear result if you move 'q{...}' outside of mixin:

Yes, that's why I write it very specifically the way I do, with q{ and mixin on the same line.

On 8/23/20 8:42 AM, Andrey Zherikov wrote:
> On Saturday, 22 August 2020 at 03:43:10 UTC, Steven Schveighoffer wrote:
>> On 8/21/20 6:34 PM, Adam D. Ruppe wrote:
>>> On Friday, 21 August 2020 at 22:12:48 UTC, Steven Schveighoffer wrote:
>>>> And honestly, if it says the source is "mixin-50, line 1", I think people will get it.
>>>
>>> I could probably live with that too, but the status quo is pretty useful as-is.
>>
>> I wonder if the compiler could detect when you are using a string literal vs. a generated or imported string, and change the behavior accordingly.
> 
> As far as I understand behavior of this is that mixin() changes __FILE__ to point to the location of this mixin. But import expression doesn't do so. So if import("file") could change __FILE__ to "file" and __LINE__ to 1 internally that will make sense IMHO.
> I mean something like this:
>                  //__FILE__='test', __LINE__=1
> mixin(          //__FILE__='test-mixin-2', __LINE__=2
>                  //__FILE__='test-mixin-2', __LINE__=3
> import("file")  //__FILE__='file', __LINE__=1           - only inside import()  !!!
>                  //__FILE__='test-mixin-2', __LINE__=5
> )
>                  //__FILE__='test', __LINE__=7
> 

import("file") returns a string, the source of the string is no longer available for the compiler after it's done importing it as a string.

However, you can easily use the #line directive to automate this...

string getImport(string file)()
{
   return "#line 1 " ~ file ~ "\n" ~ import(file);
}

mixin(getImport!"file");

-Steve