Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote: auto opDispatch(string s)() if (s == "bar") In case anyone isn't aware, this is better written: auto opDispatch(string s : "bar")()
Re: Extend the call site default argument expansion mechanism?
On Wednesday, 16 May 2018 at 10:51:51 UTC, jmh530 wrote: On Wednesday, 16 May 2018 at 09:01:29 UTC, Simen Kjærås wrote: snip] struct Foo(int x) { int n = x; auto opDispatch(string s)() if (s == "bar") { n++; return n; } } unittest { int y = 0; with(Foo!1()) { y = bar; // Works! } assert(y == 2); } -- Simen Thanks for catching that. Any idea why the original was having problems? Seems to me there's an issue with overload priority - we expect opDispatch to count before globals, but it doesn't. Filed an issue: https://issues.dlang.org/show_bug.cgi?id=18866 -- Simen
Re: Extend the call site default argument expansion mechanism?
On Wednesday, 16 May 2018 at 09:01:29 UTC, Simen Kjærås wrote: snip] struct Foo(int x) { int n = x; auto opDispatch(string s)() if (s == "bar") { n++; return n; } } unittest { int y = 0; with(Foo!1()) { y = bar; // Works! } assert(y == 2); } -- Simen Thanks for catching that. Any idea why the original was having problems?
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote: On Tuesday, 15 May 2018 at 14:52:46 UTC, Steven Schveighoffer wrote: [snip] It seems opDispatch isn't being used in the with statement. That seems like a bug, or maybe a limitation. I'm not sure how "with" works, but I assumed it would try calling as a member, and then if it doesn't work, try the call normally. Probably it's checking to see if it has that member first. Annoying... -Steve Looks like with statements ignore opDispatch. struct Foo(int x) { auto opDispatch(string s)() if (s == "bar") { return x++; } } void main() { int y = 0; with(Foo!1) { y = bar; //error: undefined identifier bar } assert(y == 2); } You've got bugs in your code: ++x has to fail for the template case, since you're trying to increment a compile-time value. This is what the call to bar is lowered to: Foo!1.opDispatch!"bar"() When you try and compile that, you get these error messages: Error: cannot modify constant 1 Error: template instance `foo.Foo!1.Foo.opDispatch!"bar"` error instantiating In addition, the with-statement in your code refers to the type Foo!1, not an instance of it. Fixed code: struct Foo(int x) { int n = x; auto opDispatch(string s)() if (s == "bar") { n++; return n; } } unittest { int y = 0; with(Foo!1()) { y = bar; // Works! } assert(y == 2); } -- Simen
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 20:31:14 UTC, jmh530 wrote: On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote: [snip] Note, it's not an issue if Foo were not a struct. This was fixed in Bug 6400 [1]l. The issue is with template instances. I have filed a new enhancement request [2] [1] https://issues.dlang.org/show_bug.cgi?id=6400 [2] https://issues.dlang.org/show_bug.cgi?id=18863 Interestingly, you can get pretty close with a struct nested in a template function, however it seems that overload resolution does not check opDispatch if a public symbol of the same name exists. this (https://run.dlang.io/is/ZzfWDs) dosen't work, but this (https://run.dlang.io/is/7zvfqc) does (notice SList & DList are not directly visible).
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote: [snip] Note, it's not an issue if Foo were not a struct. This was fixed in Bug 6400 [1]l. The issue is with template instances. I have filed a new enhancement request [2] [1] https://issues.dlang.org/show_bug.cgi?id=6400 [2] https://issues.dlang.org/show_bug.cgi?id=18863
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 14:52:46 UTC, Steven Schveighoffer wrote: [snip] It seems opDispatch isn't being used in the with statement. That seems like a bug, or maybe a limitation. I'm not sure how "with" works, but I assumed it would try calling as a member, and then if it doesn't work, try the call normally. Probably it's checking to see if it has that member first. Annoying... -Steve Looks like with statements ignore opDispatch. struct Foo(int x) { auto opDispatch(string s)() if (s == "bar") { return x++; } } void main() { int y = 0; with(Foo!1) { y = bar; //error: undefined identifier bar } assert(y == 2); }
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 14:52:46 UTC, Steven Schveighoffer wrote: Sadly with(WithAlloc!alloc) doesn't work. (If you have to use withAlloc.func everywhere, it kind of destroy the point, doesn't it?) It seems opDispatch isn't being used in the with statement. That seems like a bug, or maybe a limitation. I'm not sure how "with" works, but I assumed it would try calling as a member, and then if it doesn't work, try the call normally. Probably it's checking to see if it has that member first. Annoying... -Steve Yeah I tried it with opDispatch but it didn't work. I vaguely remember some changes being made to how lookup is done in the past year or so... but I can't find the PR in question.
Re: Extend the call site default argument expansion mechanism?
On 5/15/18 10:26 AM, Yuxuan Shui wrote: On Tuesday, 15 May 2018 at 13:59:37 UTC, jmh530 wrote: On Tuesday, 15 May 2018 at 13:16:21 UTC, Steven Schveighoffer wrote: [snip] Hm... neat idea. Somehow, opDispatch can probably be used to make this work even more generically (untested): struct WithAlloc(alias alloc) { auto opDispatch(string s, Args...)(auto ref Args args) if (__traits(compiles, mixin(s ~ "(args, alloc)"))) { mixin("return " ~ s ~ "(args, alloc);"); } } -Steve Example: https://run.dlang.io/is/RV2xIH Sadly with(WithAlloc!alloc) doesn't work. (If you have to use withAlloc.func everywhere, it kind of destroy the point, doesn't it?) It seems opDispatch isn't being used in the with statement. That seems like a bug, or maybe a limitation. I'm not sure how "with" works, but I assumed it would try calling as a member, and then if it doesn't work, try the call normally. Probably it's checking to see if it has that member first. Annoying... -Steve
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 14:26:48 UTC, Yuxuan Shui wrote: [snip] Example: https://run.dlang.io/is/RV2xIH Sadly with(WithAlloc!alloc) doesn't work. (If you have to use withAlloc.func everywhere, it kind of destroy the point, doesn't it?) Yeah I know, I tried it, but couldn't figure out how to do the with statement with it.
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 13:59:37 UTC, jmh530 wrote: On Tuesday, 15 May 2018 at 13:16:21 UTC, Steven Schveighoffer wrote: [snip] Hm... neat idea. Somehow, opDispatch can probably be used to make this work even more generically (untested): struct WithAlloc(alias alloc) { auto opDispatch(string s, Args...)(auto ref Args args) if (__traits(compiles, mixin(s ~ "(args, alloc)"))) { mixin("return " ~ s ~ "(args, alloc);"); } } -Steve Example: https://run.dlang.io/is/RV2xIH Sadly with(WithAlloc!alloc) doesn't work. (If you have to use withAlloc.func everywhere, it kind of destroy the point, doesn't it?)
Re: Extend the call site default argument expansion mechanism?
On Tuesday, 15 May 2018 at 13:16:21 UTC, Steven Schveighoffer wrote: [snip] Hm... neat idea. Somehow, opDispatch can probably be used to make this work even more generically (untested): struct WithAlloc(alias alloc) { auto opDispatch(string s, Args...)(auto ref Args args) if (__traits(compiles, mixin(s ~ "(args, alloc)"))) { mixin("return " ~ s ~ "(args, alloc);"); } } -Steve Example: https://run.dlang.io/is/RV2xIH
Re: Extend the call site default argument expansion mechanism?
On 5/15/18 7:53 AM, Yuxuan Shui wrote: On Friday, 11 May 2018 at 18:55:03 UTC, Meta wrote: On Friday, 11 May 2018 at 15:03:41 UTC, Uknown wrote: [...] It's not as pretty, and I don't know if it works outside this toy example yet, but you can do: import std.stdio; struct Allocator { auto call(alias F, Args...)(Args args) { return F(this, args); } void deallocateAll() { writeln("deallocateAll"); } } void f1(Allocator a, int n) { writeln("f1"); } void f2(Allocator, string s, double d) { writeln("f2"); } void main() { with (Allocator()) { scope(exit) deallocateAll; call!f1(2); call!f2("asdf", 1.0); } } I found another alternative to this: https://godbolt.org/g/3Etims Hm... neat idea. Somehow, opDispatch can probably be used to make this work even more generically (untested): struct WithAlloc(alias alloc) { auto opDispatch(string s, Args...)(auto ref Args args) if (__traits(compiles, mixin(s ~ "(args, alloc)"))) { mixin("return " ~ s ~ "(args, alloc);"); } } -Steve
Re: Extend the call site default argument expansion mechanism?
On Friday, 11 May 2018 at 13:22:12 UTC, Meta wrote: On Friday, 11 May 2018 at 11:42:07 UTC, Dukc wrote: On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: ... // constructor of DataStructure this(Allocator alloc=__ALLOC__) {...} ... auto alloc = new SomeAllocator(); define __ALLOC__ = alloc; // And we don't need to pass alloc everytime ... Is this a good idea? Doesn't this basically mean including the implicits Martin Odersky talked about at Dconf in D? Yes it does. I was thinking the exact same thing while watching his talk; implicits would be perfect for allocators. D doesn't have Scala's implicits though. However, one can write up a reader monad in the D we have right now. Atila
Re: Extend the call site default argument expansion mechanism?
On Friday, 11 May 2018 at 18:55:03 UTC, Meta wrote: On Friday, 11 May 2018 at 15:03:41 UTC, Uknown wrote: [...] It's not as pretty, and I don't know if it works outside this toy example yet, but you can do: import std.stdio; struct Allocator { auto call(alias F, Args...)(Args args) { return F(this, args); } void deallocateAll() { writeln("deallocateAll"); } } void f1(Allocator a, int n) { writeln("f1"); } void f2(Allocator, string s, double d) { writeln("f2"); } void main() { with (Allocator()) { scope(exit) deallocateAll; call!f1(2); call!f2("asdf", 1.0); } } I found another alternative to this: https://godbolt.org/g/3Etims
Re: Extend the call site default argument expansion mechanism?
On Friday, 11 May 2018 at 11:42:07 UTC, Dukc wrote: [snip] Doesn't this basically mean including the implicits Martin Odersky talked about at Dconf in D? I don't know whether it's a good idea all-in-all, but assuming the arguments can be used as compile-time I can already see a big use case: killing autodecoding without breaking code. Something like: auto front(C, bool disableDecoding = __NODECODE__)(inout C[] string) { static if (disableDecoding) {...} else {...} } I'm not sure this makes sense or not...but what about instead of implicits, you allow a template to have type erased parameters, basically to optionally mimic the behavior of Java's generics. That way the allocator could be included in the type and checked at compile-time, but it wouldn't be known at run-time (not sure that's a positive or not).
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 15:15:03 UTC, Paul Backus wrote: On Thursday, 10 May 2018 at 14:37:00 UTC, rikki cattermole wrote: On 11/05/2018 2:33 AM, Yuxuan Shui wrote: On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote: But doing it with default argument expansion saves you 1 allocation, has 1 less type, while being just as readable. I think that's a win. class -> struct, now it is back to 1 allocation. Even easier: alias createDataStructure = (...) => new DataStructure(..., alloc); I think one problem with this and Factory, is that you have to create one alias/lambda/factory type for every type that takes an allocator.
Re: Extend the call site default argument expansion mechanism?
On Friday, 11 May 2018 at 15:03:41 UTC, Uknown wrote: I see what you're saying and I agree with you. I think a better way would be to try and extend the `with` syntax to work with arbitrary functions, rather than only objects. That would make it more useful. So something like: --- void f1(allocator alloc, ...){} void f2(allocator alloc, ...){} ... void fn(allocator alloc, ...){} void main() { with(MyAllocator) { f1(...); f2(...); ... fn(...); } } --- It's not as pretty, and I don't know if it works outside this toy example yet, but you can do: import std.stdio; struct Allocator { auto call(alias F, Args...)(Args args) { return F(this, args); } void deallocateAll() { writeln("deallocateAll"); } } void f1(Allocator a, int n) { writeln("f1"); } void f2(Allocator, string s, double d) { writeln("f2"); } void main() { with (Allocator()) { scope(exit) deallocateAll; call!f1(2); call!f2("asdf", 1.0); } }
Re: Extend the call site default argument expansion mechanism?
On Friday, 11 May 2018 at 14:26:21 UTC, Jonathan M Davis wrote: On Thursday, May 10, 2018 14:15:18 Yuxuan Shui via Digitalmars-d wrote: So in D I can use default argument like this: [...] Is this a good idea? It seems like really risky move, honestly, because it means that the function is then affected by what is and isn't declared within the scope where it's called. __FILE__ and __LINE__ are well-defined as to what they mean. No can declare them to mean something else. You don't have symbol resolution issues or naming conflicts. And they're solving a problem that can't actually be solved without compiler help. However, if you just want to change what arguments get passed to foo within your module, all you have to do is define another foo inside the module and have it forward to the original one with whatever arguments you want. What you're suggesting here seems to introduce name pollution issues without solving anything that can't easily be solved with the language as-is. - Jonathan M Davis I see what you're saying and I agree with you. I think a better way would be to try and extend the `with` syntax to work with arbitrary functions, rather than only objects. That would make it more useful. So something like: --- void f1(allocator alloc, ...){} void f2(allocator alloc, ...){} ... void fn(allocator alloc, ...){} void main() { with(MyAllocator) { f1(...); f2(...); ... fn(...); } } ---
Re: Extend the call site default argument expansion mechanism?
On Thursday, May 10, 2018 14:15:18 Yuxuan Shui via Digitalmars-d wrote: > So in D I can use default argument like this: > > int f(int line=__LINE__) {} > > And because default argument is expanded at call site, f() will > be called with the line number of the call site. > > This is a really clever feature, and I think a similar feature > can be useful in other ways. > > Say I need to construct a bunch of data structure that takes an > Allocator argument, I need to do this: > > ... > auto alloc = new SomeAllocator(); > auto data1 = new DataStructure(..., alloc); > auto data2 = new DataStructure(..., alloc); > auto data3 = new DataStructure(..., alloc); > ... > > This looks redundant. But if we have the ability to define more > special keywords like __LINE__, we can do something like this: > > ... > // constructor of DataStructure > this(Allocator alloc=__ALLOC__) {...} > ... > auto alloc = new SomeAllocator(); > define __ALLOC__ = alloc; > // And we don't need to pass alloc everytime > ... > > Is this a good idea? It seems like really risky move, honestly, because it means that the function is then affected by what is and isn't declared within the scope where it's called. __FILE__ and __LINE__ are well-defined as to what they mean. No can declare them to mean something else. You don't have symbol resolution issues or naming conflicts. And they're solving a problem that can't actually be solved without compiler help. However, if you just want to change what arguments get passed to foo within your module, all you have to do is define another foo inside the module and have it forward to the original one with whatever arguments you want. What you're suggesting here seems to introduce name pollution issues without solving anything that can't easily be solved with the language as-is. - Jonathan M Davis
Re: Extend the call site default argument expansion mechanism?
On 10.05.2018 16:22, rikki cattermole wrote: On 11/05/2018 2:20 AM, Yuxuan Shui wrote: On Thursday, 10 May 2018 at 14:17:50 UTC, rikki cattermole wrote: On 11/05/2018 2:15 AM, Yuxuan Shui wrote: [...] Bad idea, too much magic. This magic is already there in D. I just want to use it in a different way. The magic is not already in there. __LINE__ and __MODULE__ are special, they are constants recognized by the compiler and are immediately substituted if not specified. Yes, that's essentially the definition of "magic".
Re: Extend the call site default argument expansion mechanism?
On Friday, 11 May 2018 at 11:42:07 UTC, Dukc wrote: On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: ... // constructor of DataStructure this(Allocator alloc=__ALLOC__) {...} ... auto alloc = new SomeAllocator(); define __ALLOC__ = alloc; // And we don't need to pass alloc everytime ... Is this a good idea? Doesn't this basically mean including the implicits Martin Odersky talked about at Dconf in D? Yes it does. I was thinking the exact same thing while watching his talk; implicits would be perfect for allocators.
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: ... // constructor of DataStructure this(Allocator alloc=__ALLOC__) {...} ... auto alloc = new SomeAllocator(); define __ALLOC__ = alloc; // And we don't need to pass alloc everytime ... Is this a good idea? Doesn't this basically mean including the implicits Martin Odersky talked about at Dconf in D? I don't know whether it's a good idea all-in-all, but assuming the arguments can be used as compile-time I can already see a big use case: killing autodecoding without breaking code. Something like: auto front(C, bool disableDecoding = __NODECODE__)(inout C[] string) { static if (disableDecoding) {...} else {...} }
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:37:00 UTC, rikki cattermole wrote: On 11/05/2018 2:33 AM, Yuxuan Shui wrote: On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote: But doing it with default argument expansion saves you 1 allocation, has 1 less type, while being just as readable. I think that's a win. class -> struct, now it is back to 1 allocation. Even easier: alias createDataStructure = (...) => new DataStructure(..., alloc);
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:37:00 UTC, rikki cattermole wrote: On 11/05/2018 2:33 AM, Yuxuan Shui wrote: On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote: On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: [...] But doing it with default argument expansion saves you 1 allocation, has 1 less type, while being just as readable. I think that's a win. class -> struct, now it is back to 1 allocation. Alternatively `scope`d classes would also work with dip1000
Re: Extend the call site default argument expansion mechanism?
On 11/05/2018 2:33 AM, Yuxuan Shui wrote: On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote: On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: [...] For things like this you can use the OOP Factory pattern, pseudocode: class DataStructureFactory { this(Allocator alloc) { this.alloc = alloc; } Allocator alloc; DataStructure createDataStructure(...) { return new DataStructure(..., alloc) } } DataStructureFactory factory = new DataStructureFactory(new SomeAllocator()) auto data1 = factory.createDataStructure(...) auto data2 = factory.createDataStructure(...) auto data3 = factory.createDataStructure(...) But doing it with default argument expansion saves you 1 allocation, has 1 less type, while being just as readable. I think that's a win. class -> struct, now it is back to 1 allocation.
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:30:49 UTC, Seb wrote: On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: So in D I can use default argument like this: int f(int line=__LINE__) {} [...] Why not define a TLS or global variable like theAllocator? Or if you know it at compile-time as an alias? Because my proposal is better encapsulated. Definitions of expanded default arguments are scoped, so in the given example, you can have different __ALLOC__ in different scope, where different allocators might be needed. My proposal is basically an alias, but an alias which is recognized by compiler as subtitution keywords for default arguments (like __LINE__, __FILE__).
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote: On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: [...] For things like this you can use the OOP Factory pattern, pseudocode: class DataStructureFactory { this(Allocator alloc) { this.alloc = alloc; } Allocator alloc; DataStructure createDataStructure(...) { return new DataStructure(..., alloc) } } DataStructureFactory factory = new DataStructureFactory(new SomeAllocator()) auto data1 = factory.createDataStructure(...) auto data2 = factory.createDataStructure(...) auto data3 = factory.createDataStructure(...) But doing it with default argument expansion saves you 1 allocation, has 1 less type, while being just as readable. I think that's a win.
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: So in D I can use default argument like this: int f(int line=__LINE__) {} [...] Why not define a TLS or global variable like theAllocator? Or if you know it at compile-time as an alias?
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote: So in D I can use default argument like this: int f(int line=__LINE__) {} And because default argument is expanded at call site, f() will be called with the line number of the call site. This is a really clever feature, and I think a similar feature can be useful in other ways. Say I need to construct a bunch of data structure that takes an Allocator argument, I need to do this: ... auto alloc = new SomeAllocator(); auto data1 = new DataStructure(..., alloc); auto data2 = new DataStructure(..., alloc); auto data3 = new DataStructure(..., alloc); ... This looks redundant. But if we have the ability to define more special keywords like __LINE__, we can do something like this: ... // constructor of DataStructure this(Allocator alloc=__ALLOC__) {...} ... auto alloc = new SomeAllocator(); define __ALLOC__ = alloc; // And we don't need to pass alloc everytime ... Is this a good idea? For things like this you can use the OOP Factory pattern, pseudocode: class DataStructureFactory { this(Allocator alloc) { this.alloc = alloc; } Allocator alloc; DataStructure createDataStructure(...) { return new DataStructure(..., alloc) } } DataStructureFactory factory = new DataStructureFactory(new SomeAllocator()) auto data1 = factory.createDataStructure(...) auto data2 = factory.createDataStructure(...) auto data3 = factory.createDataStructure(...)
Re: Extend the call site default argument expansion mechanism?
On 11/05/2018 2:20 AM, Yuxuan Shui wrote: On Thursday, 10 May 2018 at 14:17:50 UTC, rikki cattermole wrote: On 11/05/2018 2:15 AM, Yuxuan Shui wrote: [...] Bad idea, too much magic. This magic is already there in D. I just want to use it in a different way. The magic is not already in there. __LINE__ and __MODULE__ are special, they are constants recognized by the compiler and are immediately substituted if not specified.
Re: Extend the call site default argument expansion mechanism?
On Thursday, 10 May 2018 at 14:17:50 UTC, rikki cattermole wrote: On 11/05/2018 2:15 AM, Yuxuan Shui wrote: [...] Bad idea, too much magic. This magic is already there in D. I just want to use it in a different way.
Extend the call site default argument expansion mechanism?
So in D I can use default argument like this: int f(int line=__LINE__) {} And because default argument is expanded at call site, f() will be called with the line number of the call site. This is a really clever feature, and I think a similar feature can be useful in other ways. Say I need to construct a bunch of data structure that takes an Allocator argument, I need to do this: ... auto alloc = new SomeAllocator(); auto data1 = new DataStructure(..., alloc); auto data2 = new DataStructure(..., alloc); auto data3 = new DataStructure(..., alloc); ... This looks redundant. But if we have the ability to define more special keywords like __LINE__, we can do something like this: ... // constructor of DataStructure this(Allocator alloc=__ALLOC__) {...} ... auto alloc = new SomeAllocator(); define __ALLOC__ = alloc; // And we don't need to pass alloc everytime ... Is this a good idea?
Re: Extend the call site default argument expansion mechanism?
On 11/05/2018 2:15 AM, Yuxuan Shui wrote: So in D I can use default argument like this: int f(int line=__LINE__) {} And because default argument is expanded at call site, f() will be called with the line number of the call site. This is a really clever feature, and I think a similar feature can be useful in other ways. Say I need to construct a bunch of data structure that takes an Allocator argument, I need to do this: ... auto alloc = new SomeAllocator(); auto data1 = new DataStructure(..., alloc); auto data2 = new DataStructure(..., alloc); auto data3 = new DataStructure(..., alloc); ... This looks redundant. But if we have the ability to define more special keywords like __LINE__, we can do something like this: ... // constructor of DataStructure this(Allocator alloc=__ALLOC__) {...} ... auto alloc = new SomeAllocator(); define __ALLOC__ = alloc; // And we don't need to pass alloc everytime ... Is this a good idea? Bad idea, too much magic.