proposal: better stack trace support could advantageously replace implicit __FILE__/__LINE__ parameters

Timothee Cour thelastmammoth at gmail.com
Sat Aug 17 02:18:11 PDT 2013


On Sat, Aug 17, 2013 at 1:54 AM, Andrej Mitrovic <andrej.mitrovich at gmail.com
> wrote:

> On 8/17/13, Timothee Cour <thelastmammoth at gmail.com> wrote:
> > 1) impossible to have variadic arguments with an extra file/line
> parameters
> > at the end (unless one makes those file/line as compile time parameters
> but
> > that makes template code bloat), which would be very useful for debugging
>
> This is a more general problem, I hope we can solve this one day.
> http://d.puremagic.com/issues/show_bug.cgi?id=8687

That would be a partial fix only, as it would be impossible to override the
file/line parameters in case of forwarding. WRT 8687, a better solution
would be named parameters arguments (as I've suggested many times before):

void fun(T...)(T args, string file : __FILE__, int line : __LINE__ ){}

called with:

fun(1,2,3) => file =__FILE__,line=__LINE__
fun(1,2,3,file:"fun.d") => file ="fun.d",line=__LINE__
fun(1,2,3, line :24) => file =__FILE__,line=24
fun(1,2,3, line :24 , file:"fun.d") => file ="fun.d",line=24

This results in no ambiguity and still gives flexibility to override the
defaults. Parameters marked with ":" *have* to be named at call site.
Optionally, no default may be provided: void fun(T...)(T args, string file:
, int nb_cols:){}



> > Furthermore, if we later want to add more information to the context (eg
> > __MODULE__,__FUNCTION__, __COLUMN__ or __ARGUMENTS__), we would have to
> > refactor a lot of code.
>
> P.S. __MODULE__, __FUNCTION__ and __PRETTY_FUNCTION__ were added in 2.063.
>
> Anywho, I agree it's a bit tedious having to explicitly use these as
> parameters.
>
> I once suggested to have a single __CONTEXT__ parameter which held
> various caller information inside of a struct (e.g. a struct with a
> file, line, function fields), it would at least make it easier to use
> since it would be just one parameter instead of several, but I didn't
> get a positive response for the feature.
>

I was also in favor of this (better than having to list explicitly each of
LINE,FILE...) but somehow if I remember andrei was against it to keep
things simple. I disagree with the 'keep it simple' argument (really it
doesn't add much to the compiler but simplifies user code), however it may
be a bit inefficient to pass around everything in context.

Which is why I am proposing instead proper stacktrace support for maximum
efficiency and ease of user code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130817/e62b0711/attachment.html>


More information about the Digitalmars-d mailing list