I have some reflection-heavy validation code, it's necessary that I emit meaningful error messages to the user explaining when inputs don't meet expectation.

I'm finding that emitting an FQN along with the error messages is not
super productive.
I'd REALLY like to emit the error with the proper file and line prefix
so that you can click and code editors will go to the problem
declaration.

I can't find any way to dig the Loc of the declaration from the symbol reference. Does anyone know any tricks? Should I make a PR to expose the symbol Loc as a traits?

On Sunday, 9 June 2019 at 21:26:52 UTC, Manu wrote:
> I have some reflection-heavy validation code, it's necessary that I emit meaningful error messages to the user explaining when inputs don't meet expectation.
>
> I'm finding that emitting an FQN along with the error messages is not
> super productive.
> I'd REALLY like to emit the error with the proper file and line prefix
> so that you can click and code editors will go to the problem
> declaration.
>
> I can't find any way to dig the Loc of the declaration from the symbol reference. Does anyone know any tricks? Should I make a PR to expose the symbol Loc as a traits?

I have a very similar use case. I need for a module name the filename. I also thought about s.th. like
__traits(file, "module name")
The idea is, the return value is the same like __FILE__ in the scope of the module.

Anything which would enable it would be very welcome.

Kind regards
Andre

On Sun, Jun 9, 2019 at 2:40 PM Andre Pany via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 9 June 2019 at 21:26:52 UTC, Manu wrote:
> > I have some reflection-heavy validation code, it's necessary that I emit meaningful error messages to the user explaining when inputs don't meet expectation.
> >
> > I'm finding that emitting an FQN along with the error messages
> > is not
> > super productive.
> > I'd REALLY like to emit the error with the proper file and line
> > prefix
> > so that you can click and code editors will go to the problem
> > declaration.
> >
> > I can't find any way to dig the Loc of the declaration from the symbol reference. Does anyone know any tricks? Should I make a PR to expose the symbol Loc as a traits?
>
> I have a very similar use case. I need for a module name the
> filename. I also thought about s.th. like
> __traits(file, "module name")
> The idea is, the return value is the same like __FILE__ in the
> scope of the module.
>
> Anything which would enable it would be very welcome.

I'm thinking something like: __traits(getLoc, symbol) ==
AliasSeq!(file, line, column) for the declaration of the symbol
specified.

On Sunday, 9 June 2019 at 22:17:08 UTC, Manu wrote:
> I'm thinking something like: __traits(getLoc, symbol) ==
> AliasSeq!(file, line, column) for the declaration of the symbol
> specified.

https://github.com/dlang/dmd/pull/10013

On Sunday, 9 June 2019 at 21:26:52 UTC, Manu wrote:

> I'd REALLY like to emit the error with the proper file and line prefix
> so that you can click and code editors will go to the problem
> declaration.
>
> I can't find any way to dig the Loc of the declaration from the symbol reference. Does anyone know any tricks? Should I make a PR to expose the symbol Loc as a traits?

This is actually a very good idea, IMO.  I actually see a lot of potential in the D's traits system for exposing more information like this from the compiler to users' programs.  I'd like to the traits feature set judiciously expanded with such things.  So thumbs up from me.

Mike

On Monday, 10 June 2019 at 01:58:37 UTC, Mike Franklin wrote:

> This is actually a very good idea, IMO.  I actually see a lot of potential in the D's traits system for exposing more information like this from the compiler to users' programs.  I'd like to the traits feature set judiciously expanded with such things.  So thumbs up from me.

Man! The more I wordsmith my writing the worse it gets.  Here's what I meant to say.

This is actually a very good idea, IMO.  I see a lot of potential in D's traits system for exposing more information like this from the compiler to users' programs.  I'd like to see the traits feature set judiciously expanded with such things.  So thumbs up from me.

Mike

On Monday, 10 June 2019 at 02:02:29 UTC, Mike Franklin wrote:
> On Monday, 10 June 2019 at 01:58:37 UTC, Mike Franklin wrote:
>
>> This is actually a very good idea, IMO.  I actually see a lot of potential in the D's traits system for exposing more information like this from the compiler to users' programs.  I'd like to the traits feature set judiciously expanded with such things.  So thumbs up from me.
>
> Man! The more I wordsmith my writing the worse it gets.  Here's what I meant to say.
>
> This is actually a very good idea, IMO.  I see a lot of potential in D's traits system for exposing more information like this from the compiler to users' programs.  I'd like to see the traits feature set judiciously expanded with such things.  So thumbs up from me.
>
> Mike

+1

Symbols are very important in many points of view, beginning from the start of the work.

On Monday, 10 June 2019 at 01:04:42 UTC, Nicholas Wilson wrote:
> On Sunday, 9 June 2019 at 22:17:08 UTC, Manu wrote:
>> I'm thinking something like: __traits(getLoc, symbol) ==
>> AliasSeq!(file, line, column) for the declaration of the symbol
>> specified.
>
> https://github.com/dlang/dmd/pull/10013

I read a Twitter post from Adam about it and initially thought it was for getting the "lines of code" (LoC) of a function. Would that also make sense as a trait?

On Monday, 10 June 2019 at 01:04:42 UTC, Nicholas Wilson wrote:
> On Sunday, 9 June 2019 at 22:17:08 UTC, Manu wrote:
>> I'm thinking something like: __traits(getLoc, symbol) ==
>> AliasSeq!(file, line, column) for the declaration of the symbol
>> specified.
>
> https://github.com/dlang/dmd/pull/10013

This is awesome, didn't saw the pr before. I am going to use it to create css sourcemaps.