When the file is specified, Shouldn't #line create a new module ?

===========
module m;

int a;

#line 0 "other.d"

int a;
===========

Currently this is not allowed, but what's the value added by the filename then ?

On 09/24/2016 10:14 AM, Basile B. wrote:
> When the file is specified, Shouldn't #line create a new module ?
> 
> ===========
> module m;
> 
> int a;
> 
> #line 0 "other.d"
> 
> int a;
> ===========
> 
> Currently this is not allowed, but what's the value added by the filename then ?

It was used to easier debug string mixins by changing their filename in reported errors. Now it is done by compiler by default and I don't know if any other use case remains.

But is definitely is not intended to create a new module, D relies on strict 1-to-1 matching between files and modules.

On Saturday, 24 September 2016 at 07:14:47 UTC, Basile B. wrote:
> When the file is specified, Shouldn't #line create a new module ?
>
> ===========
> module m;
>
> int a;
>
> #line 0 "other.d"
>
> int a;
> ===========
>
> Currently this is not allowed, but what's the value added by the filename then ?

Debugging in mixins is the usage of it.

On Saturday, 24 September 2016 at 09:23:38 UTC, Dicebot wrote:
> On 09/24/2016 10:14 AM, Basile B. wrote:
>> When the file is specified, Shouldn't #line create a new module ?
>> [...]
>> Currently this is not allowed, but what's the value added by the filename then ?
>
> It was used to easier debug string mixins by changing their filename in reported errors. Now it is done by compiler by default and I don't know if any other use case remains.
>
> But is definitely is not intended to create a new module, D relies on strict 1-to-1 matching between files and modules.

Then I suggest to deprecate it. It was not totally illegitimate to think that it allows to create a new module.

Also since no more special token sequence would exist in the language, special token sequence could be removed completely.

On Sunday, 25 September 2016 at 07:30:49 UTC, Basile B. wrote:
> Also since no more special token sequence would exist in the language, special token sequence could be removed completely.

That's https://issues.dlang.org/show_bug.cgi?id=2660

On Monday, 26 September 2016 at 10:19:09 UTC, Kagamin wrote:
> On Sunday, 25 September 2016 at 07:30:49 UTC, Basile B. wrote:
>> Also since no more special token sequence would exist in the language, special token sequence could be removed completely.
>
> That's https://issues.dlang.org/show_bug.cgi?id=2660

Yep, I also want an HackerPilot POV about this. He's the official guy for grammar stuff.

On Monday, 26 September 2016 at 11:37:51 UTC, Basile B. wrote:
> On Monday, 26 September 2016 at 10:19:09 UTC, Kagamin wrote:
>> On Sunday, 25 September 2016 at 07:30:49 UTC, Basile B. wrote:
>>> Also since no more special token sequence would exist in the language, special token sequence could be removed completely.
>>
>> That's https://issues.dlang.org/show_bug.cgi?id=2660
>
> Yep, I also want an HackerPilot POV about this. He's the official guy for grammar stuff.

To be clear, the problem is: if "SpecialTokenSequence" is removed then does "#" become a valid character for identifiers (type naming, variable naming).
Example:

struct S{#i int;}

would be be a struct declaration with an inside declaration.

On Sunday, 25 September 2016 at 07:30:49 UTC, Basile B. wrote:
> On Saturday, 24 September 2016 at 09:23:38 UTC, Dicebot wrote:
>> On 09/24/2016 10:14 AM, Basile B. wrote:
>>> When the file is specified, Shouldn't #line create a new module ?
>>> [...]
>>> Currently this is not allowed, but what's the value added by the filename then ?
>>
>> It was used to easier debug string mixins by changing their filename in reported errors. Now it is done by compiler by default and I don't know if any other use case remains.
>>
>> But is definitely is not intended to create a new module, D relies on strict 1-to-1 matching between files and modules.
>
> Then I suggest to deprecate it. It was not totally illegitimate to think that it allows to create a new module.
>

+1 (It also doesn't jive with the __FILE_FULL_PATH__ intrinsic)