On 2012-09-04 15:36, Andrej Mitrovic wrote:
>   9/4/12, Ellery Newcomer<ellery-newcomer@utulsa.edu>  wrote:
>> On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:
>>> __FILE__?
>>>
>>
>> It doesn't necessarily have the exact package hierarchy.
>
> We could really use __MODULE__ then. I think it's been asked before
> but I didn't see any enhancement request in buzilla.

+1 would love this too

so far tried to get away with __FILE__ but this has issues, as noted before.


on a slightly different note, __FILE__ and __LINE__ are not quite doing what they are supposed to do either:

http://dlang.org/template.html
Template Value Parameters
"The __FILE__ and __LINE__ expand to the source file name and line number at the point of instantiation."

unfortunately, they only do this for functions (sort of¹), not for other templates. dunno why, i think it is just not implemented. in fear of code bloat? i don't get this argument though. if you use __FILE__ and such extensively it would be only in debugging scenarios. other than that, you shouldn't have many of those. at least this is the case in my code. and the danger of code bloat with templates is omnipresent, no reason to single out __FILE__ usage.

¹using funtempl(Ps)(As){...}:
+ always works in argument list (As), also in non-templated functions
+ as template parameter (P), works only when called short: funtempl()
- as template parameter(P), this does not work: funtempl!()()

On Sep 5, 2012, at 10:56, captaindet <2krnk@gmx.net> wrote:

> On 2012-09-04 15:36, Andrej Mitrovic wrote:
>>  9/4/12, Ellery Newcomer<ellery-newcomer@utulsa.edu>  wrote:
>>> On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:
>>>> __FILE__?
>>>>
>>>
>>> It doesn't necessarily have the exact package hierarchy.
>>
>> We could really use __MODULE__ then. I think it's been asked before
>> but I didn't see any enhancement request in buzilla.
>
> +1 would love this too
>
> so far tried to get away with __FILE__ but this has issues, as noted before.
>
>
> on a slightly different note, __FILE__ and __LINE__ are not quite doing what they are supposed to do either:
>
> http://dlang.org/template.html
> Template Value Parameters
> "The __FILE__ and __LINE__ expand to the source file name and line number at the point of instantiation."
>
> unfortunately, they only do this for functions (sort of¹), not for other templates.

It should work for templates too; std.log uses this extensively. Or at least it used to work. Can you post the code sample where it doesn't work?

On Wednesday, September 05, 2012 11:05:10 Jose Armando Garcia wrote:
> It should work for templates too; std.log uses this extensively. Or at least it used to work. Can you post the code sample where it doesn't work?

Regardless of whether it works, __FILE__ and __LINE__ should be used as template arguments with extreme caution, because you end up with a new instantiation for _every_ use (at least if you use both together).

If it's broken, it should certainly be fixed, but it's not a feature to be used lightly.

- Jonathan M Davis

On 9/5/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Regardless of whether it works, __FILE__ and __LINE__ should be used as template arguments with extreme caution, because you end up with a new instantiation for _every_ use (at least if you use both together).

Honestly it would be much better if the file and line were symbols you could retrieve at any point in your function, e.g.:

void foo()
{
    string file = __FILE__;  // file of inside
    int line = __LINE__;  // line inside foo

    string callFile = __INFILE__;  // file of invocation
    int line = __INLINE__;  // line of invocation
}

That way you don't have to mess with your CT/RT parameters if all you want to do is printf-style debugging.

On Wednesday, September 05, 2012 20:46:08 Andrej Mitrovic wrote:
> On 9/5/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > Regardless of whether it works, __FILE__ and __LINE__ should be used as template arguments with extreme caution, because you end up with a new instantiation for _every_ use (at least if you use both together).
> 
> Honestly it would be much better if the file and line were symbols you could retrieve at any point in your function, e.g.:
> 
> void foo()
> {
> string file = __FILE__; // file of inside
> int line = __LINE__; // line inside foo
> 
> string callFile = __INFILE__; // file of invocation
> int line = __INLINE__; // line of invocation
> }
> 
> That way you don't have to mess with your CT/RT parameters if all you want to do is printf-style debugging.

That would be _way_ harder to implement. As it is, it's trivial to insert the __FILE__ and __LINE__ as default arguments at the call site. Doing __INFILE__ or __INLINE__ would require providing additional, invisible arguments to the function for the __FILE__ and __LINE__ at the call site, and it would invisibly change the function's signature depending on whether __INFILE__ and/or __INLINE__ were used in the function or not. I'd be very surprised if that sort of thing were considered acceptable by the compiler devs.

With how C linkage is designed, it doesn't care about the call site at all. A function has no idea where it's called from and doesn't care. The only reason that we got __FILE__ and __LINE__ to work like they do with default arguments is because it was trivial to change it so that they used the values at the call site rather than the declaration site, because those values are copy- pasted at the call site anyway. Anything which would require the function itself actually having access to the scope that it was called from would complicate things considerably.

- Jonathan M Davis

On 9/5/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> That would be _way_ harder to implement.

Right, this would only work for templated functions, but maybe not worth adding then.

On 2012-09-05 13:05, Jose Armando Garcia wrote:
> On Sep 5, 2012, at 10:56, captaindet <2krnk@gmx.net> wrote:
>
>> On 2012-09-04 15:36, Andrej Mitrovic wrote:
>>> 9/4/12, Ellery Newcomer<ellery-newcomer@utulsa.edu> wrote:
>>>> On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:
>>>>> __FILE__?
>>>>>
>>>>
>>>> It doesn't necessarily have the exact package hierarchy.
>>>
>>> We could really use __MODULE__ then. I think it's been asked
>>> before but I didn't see any enhancement request in buzilla.
>>
>> +1 would love this too
>>
>> so far tried to get away with __FILE__ but this has issues, as
>> noted before.
>>
>>
>> on a slightly different note, __FILE__ and __LINE__ are not quite
>> doing what they are supposed to do either:
>>
>> http://dlang.org/template.html Template Value Parameters "The
>> __FILE__ and __LINE__ expand to the source file name and line
>> number at the point of instantiation."
>>
>> unfortunately, they only do this for functions (sort of¹), not for
>> other templates.
>
> It should work for templates too; std.log uses this extensively. Or
> at least it used to work. Can you post the code sample where it
> doesn't work?


i had a quick look at std.log and it seems to use __LINE__ and __FILE__ only as function argument defaults or parameter defaults for templated functions. these are the only cases where it actually works (with the one syntax catch though). however, it does not work for bare/mixin tamplates, templated structs or templated classes. (so i ended up writing factory functions for my code)

here a test program:
/**
__LINE__ testing for
F := function   S := struct     C := class      T := template
MT := mixin template

as
A := function value argument    P := template value parameter

using dmd2.060 /windows prints:
Instantiating Code starts line: 63

F(A)
OK : captured line = 67

T(P)
FAIL : captured line = 43

MT(P)
FAIL : captured line =  46

TF()(A)
OK : captured line = 78

TF(P)(): short call syntax: TF_P()
OK : captured line = 82

TF(P)(): longer call syntax: TF_P!()()
FAIL : captured line = 52

TS(P)
FAIL : captured line = 55

TC(P)
FAIL : captured line = 58
**/

module testline;
import std.stdio;

size_t F_A( size_t l = __LINE__ ){
	return l; }
	
template T_P( size_t l = __LINE__ ){
	enum size_t t_p = l; }
	
mixin template MT_P( size_t l = __LINE__ ){
	enum size_t mt_p = l; }
	
size_t TF_A()( size_t l = __LINE__ ){
	return l; }
	
size_t TF_P( size_t l = __LINE__ )(){
	enum size_t _l = l; return _l; }
	
struct TS_P( size_t l = __LINE__ ){
	size_t _l = l; }
	
class TC_P( size_t l = __LINE__ ){
	size_t _l = l; }
	
	
void main(){
	size_t L = __LINE__;		// if things work: __LINE__ > L
	writeln("\nInstantiating Code starts line: ", L);
	
	writeln("\nF(A)");
	auto l_f_a = F_A();
	writeln((l_f_a>L)?"OK":"FAIL", " : captured line = ", l_f_a);

	writeln("\nT(P)");
	writeln((T_P!().t_p>L)?"OK":"FAIL", " : captured line = ", T_P!().t_p);
	
	writeln("\nMT(P)");
	mixin MT_P!();
	writeln((mt_p>L)?"OK":"FAIL", " : captured line =  ", mt_p);
	
	writeln("\nTF()(A)");
	auto l_tf_a = TF_A!()();
	writeln((l_tf_a>L)?"OK":"FAIL", " : captured line = ", l_tf_a);

	writeln("\nTF(P)(): short call syntax: TF_P()");
	auto l_tf_p = TF_P();
	writeln((l_tf_p>L)?"OK":"FAIL", " : captured line = ", l_tf_p);

	writeln("\nTF(P)(): longer call syntax: TF_P!()()");
	auto l_tf_p2 = TF_P!()();
	writeln((l_tf_p2>L)?"OK":"FAIL", " : captured line = ", l_tf_p2);

	writeln("\nTS(P)");
	TS_P!() ts_p;
	writeln((ts_p._l>L)?"OK":"FAIL", " : captured line = ", ts_p._l);

	writeln("\nTC(P)");
	auto tc_p = new TC_P!();	
	writeln((tc_p._l>L)?"OK":"FAIL", " : captured line = ", tc_p._l);
}