On 5/30/18 4:46 AM, FeepingCreature wrote:
> Updated subject to be visible at a glance.
> 
> Note that a compiler-based solution via __CALLER__ would still work.

I saw this after I replied. Oops :)

I think it's a good idea, and I'm also believing that the issue that causes it not to work really could be addressed quite easily.

-Steve

On Wednesday, 30 May 2018 at 12:22:28 UTC, FeepingCreature wrote:
> On Wednesday, 30 May 2018 at 10:05:42 UTC, H. S. Teoh wrote:
>> What about this?
>>
>> ------
>> struct EndOfArgs { }
>> EndOfArgs eoa;
>>
>> void func(string s, EndOfArgs _ = eoa,
>> 	string file = __FILE__, size_t line = __LINE__)
>> {
>> 	import std.stdio;
>> 	writefln("%s:%d: msg=%s", file, line, s);
>> }
>>
>> void main() {
>> 	func("hello");
>> 	func("there");
>> }
>> ------
>>
>>
>> Basically, use a dummy empty struct to differentiate between real arguments and context info.
>>
>>
>> T
>
> Thank you, this seems to work well!
>
> We're using struct Fence { } Fence _ = Fence(), and it doesn't add much overhead.
>
> Barring the proposed compiler change, this seems the cleanest fix.

void func(NONE...)(string s, NONE, string file = __FILE__, size_t line = __LINE__) if(!NONE.length)
{
	import std.stdio;
	writefln("%s:%d: msg=%s", file, line, s);
}

void main() {func("hello"); func("there");
}

On 5/30/18 3:05 PM, Daniel N wrote:

> void func(NONE...)(string s, NONE, string file = __FILE__, size_t line = __LINE__) if(!NONE.length)
> {
>      import std.stdio;
>      writefln("%s:%d: msg=%s", file, line, s);
> }
> 
> void main() {func("hello"); func("there");
> }

Very cool and interesting pattern. If you now wanted to wrap the function (let's say the caller of this wants to forward it's own called file/line to it), you could do this as well:

func!()("boo", file, line);

I still think we should be able to wrap __FILE__ and __LINE__ into another call without having the wrapping take over the file/line combo.

-Steve

On 5/30/18 10:40 AM, Steven Schveighoffer wrote:
> But if we fixed the behavior that causes your idea not to work, then we could probably easily define a function like so:
> 
> CallerInfo __CALLER__(string file = __FILE__, size_t line = __LINE__)
> {
>      return CallerInfo(file, line);
> }

Filed an issue so it's not forgotten:

https://issues.dlang.org/show_bug.cgi?id=18919

-Steve

On 05/30/2018 10:40 AM, Steven Schveighoffer wrote:
> 
> But if we fixed the behavior that causes your idea not to work, then we could probably easily define a function like so:
> 
> CallerInfo __CALLER__(string file = __FILE__, size_t line = __LINE__)
> {
>      return CallerInfo(file, line);
> }
> 

Love it!

On Wednesday, 30 May 2018 at 19:34:55 UTC, Steven Schveighoffer wrote:
> On 5/30/18 3:05 PM, Daniel N wrote:
>
>> void func(NONE...)(string s, NONE, string file = __FILE__, size_t line = __LINE__) if(!NONE.length)
>> {
>>      import std.stdio;
>>      writefln("%s:%d: msg=%s", file, line, s);
>> }
>> 
>> void main() {func("hello"); func("there");
>> }
>
> Very cool and interesting pattern. If you now wanted to wrap the function (let's say the caller of this wants to forward it's own called file/line to it), you could do this as well:
>
> func!()("boo", file, line);
>

Heh, didn't consider that use-case, cool indeed!
How about we name the pattern "You shall not pass"/"None shall pass"? ;)

> I still think we should be able to wrap __FILE__ and __LINE__ into another call without having the wrapping take over the file/line combo.
>
> -Steve

Agree, adheres to the Principle of least astonishment.

On Wed, May 30, 2018 at 03:34:55PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 5/30/18 3:05 PM, Daniel N wrote:
> 
> > void func(NONE...)(string s, NONE, string file = __FILE__, size_t
> > line = __LINE__) if(!NONE.length)
> > {
> >      import std.stdio;
> >      writefln("%s:%d: msg=%s", file, line, s);
> > }
> > 
> > void main() {func("hello"); func("there");
> > }
> 
> Very cool and interesting pattern.
[...]

Note that this requires a recent version of DMDFE, because earlier versions are unable to handle additional arguments after a "..." parameter.


T

-- 
Why ask rhetorical questions? -- JC

On Wednesday, 30 May 2018 at 14:40:50 UTC, Steven Schveighoffer wrote:
> On 5/30/18 4:27 AM, FeepingCreature wrote:
>> There's a very common idiom where in order to report line numbers of an error or a log line at the callsite of a function, you pass __FILE__ and __LINE__ as default parameters:
>> 
>> void foo(string file = __FILE__, size_t line = __LINE__);
>> 
>> What's wrong with this?
>> 
>> Say you add a string parameter, such as
>> 
>> void foo(string msg, string file = __FILE__, size_t line = __LINE__);
>> 
>> foo("Hello World");
>> 
>> Now when you accidentally grab an old version of the library, your new code will still run, but it will believe that it's being called from file "Hello World", line 15. Not good.
>> 
>> Luckily there's a fix. Just stick this in some common header file in your project:
>> 
>> struct CallerInfo
>> {
>>    string file;
>>    size_t line;
>> }
>> 
>> void foo(string msg, CallerInfo caller = CallerInfo(__FILE__, __LINE__));
>> 
>> Now you cannot accidentally invoke foo with a string, or in fact any type except another instance of CallerInfo.
>
> Awesome idea! Unfortunately, it doesn't work. The __FILE__ and __LINE__ there are not from the caller, but from the line that defines foo.
>
> See here: https://run.dlang.io/is/siz9YZ
>

https://run.dlang.io/is/oMe7KQ

Less elegant, but solves the problem of accidental argument adding (CallerFile acts as a barrier). Unfortunately, while it works in theory, in practice the compiler crashes.... LOL

On Wednesday, 30 May 2018 at 14:40:50 UTC, Steven Schveighoffer wrote:
> On 5/30/18 4:27 AM, FeepingCreature wrote:
>> There's a very common idiom where in order to report line numbers of an error or a log line at the callsite of a function, you pass __FILE__ and __LINE__ as default parameters:
>> 
>> void foo(string file = __FILE__, size_t line = __LINE__);
>> 
>> What's wrong with this?
>> 
>> Say you add a string parameter, such as
>> 
>> void foo(string msg, string file = __FILE__, size_t line = __LINE__);
>> 
>> foo("Hello World");
>> 
>> Now when you accidentally grab an old version of the library, your new code will still run, but it will believe that it's being called from file "Hello World", line 15. Not good.
>> 
>> Luckily there's a fix. Just stick this in some common header file in your project:
>> 
>> struct CallerInfo
>> {
>>    string file;
>>    size_t line;
>> }
>> 
>> void foo(string msg, CallerInfo caller = CallerInfo(__FILE__, __LINE__));
>> 
>> Now you cannot accidentally invoke foo with a string, or in fact any type except another instance of CallerInfo.
>
> Awesome idea! Unfortunately, it doesn't work. The __FILE__ and __LINE__ there are not from the caller, but from the line that defines foo.
>
> See here: https://run.dlang.io/is/siz9YZ
>
>> At which point we can shorten this to CallerInfo caller = __CALLER__, and be forward compatible for additional information about the callsite, such as, say, attributes of the calling function.
>
> Hm.. I don't like this too much. Adding more magic to the compiler seems unnecessary.
>
> But if we fixed the behavior that causes your idea not to work, then we could probably easily define a function like so:
>
> CallerInfo __CALLER__(string file = __FILE__, size_t line = __LINE__)
> {
>     return CallerInfo(file, line);
> }
>
> -Steve

Instead of these hack keywords.

Perhaps a __traits() in the compiler with the information would be better suited like:


void foo()
{
    enum caller = __traits(getCaller);

    ....
}

getCaller would return a compile-time struct with additional information about the current module and the module/function it was called from.

Alternatively you can use the following traits.

true/false as secondary argument for whether it should be its current module or the call module/function etc. This argument should be optional and when omitted should default to the callee.

    __FILE__ -- __traits(getFile);
    __FILE_FULL_PATH__ -- __traits(getFilePath);
    __MODULE__ -- __traits(getModule);
    __LINE__  -- __traits(getLine);
    __FUNCTION__ -- __traits(getFunction);
    __PRETTY_FUNCTION__ -- __traits(getPrettyFunction);

On 5/31/18 7:14 AM, bauss wrote:
> Instead of these hack keywords.
> 
> Perhaps a __traits() in the compiler with the information would be better suited like:
> 
> 
> void foo()
> {
>      enum caller = __traits(getCaller);
> 
>      ....
> }
> 
> getCaller would return a compile-time struct with additional information about the current module and the module/function it was called from.

How can this be possible? When inside the function, you have no idea where you were called from.

-Steve