digitalmars.D - 'Auto can only be used for template function arguments' what?
- Mehrdad (3/3) Jun 26 2012 void test1(T)(auto ref T) { }
- Timon Gehr (3/6) Jun 26 2012 There is not. I suppose the compiler completes instantiation without
- Mehrdad (5/13) Jun 26 2012 Well the problem manifests itself in different ways, but would it
- Jonathan M Davis (3/20) Jun 26 2012 That isn't legal. auto ref can only be used with templated functions.
- Mehrdad (21/24) Jun 26 2012 The trouble is, distinguishing between when it should be illegal
- Jonathan M Davis (15/48) Jun 26 2012 And how would that work? auto ref duplicates the function. If you pass i...
- Mehrdad (7/9) Jun 26 2012 Two solutions:
- Jonathan M Davis (11/23) Jun 26 2012 That at least sounds like it would work. Walter may have a reason why it...
- kenji hara (7/30) Jun 26 2012 After considering about 'auto ref', I was concluded that is an
- Timon Gehr (3/26) Jun 27 2012 How does it deal with this case?
- kenji hara (5/46) Jun 27 2012 In this case, arg might bind rvalue allocated in the caller of id, so
- Timon Gehr (6/54) Jun 27 2012 This is a quite severe limitation compared to how auto ref works today.
- Jonathan M Davis (7/59) Jun 27 2012 Considering that if you said that a parameter is auto ref, you're basica...
- Artur Skawina (6/63) Jun 27 2012 That's not what auto-ref does. We already had this discussion. auto-ref ...
- Artur Skawina (6/12) Jun 27 2012 To clarify - /avoiding a copy/ is not the only, or even the main, use of
- Artur Skawina (5/30) Jun 27 2012 Please do not remove useful functionality in order to fix unrelated
- bearophile (5/6) Jun 27 2012 Introducing yet more modifiers and complexity should be done only
- Jonathan M Davis (4/30) Jun 26 2012 If it can be done, I'm all for it. We really need a solution to this pro...
- Jonathan M Davis (3/33) Jun 27 2012 What functionality are you talking about? What would you lose?
- Jonathan M Davis (12/24) Jun 27 2012 The _entire_ reason that auto ref on parameters was introduced in the fi...
void test1(T)(auto ref T) { } void test2() { int a = 5; test1!(int)(a); } Is there any reason this should fail?
Jun 26 2012
On 06/26/2012 06:17 PM, Mehrdad wrote:void test1(T)(auto ref T) { } void test2() { int a = 5; test1!(int)(a); } Is there any reason this should fail?There is not. I suppose the compiler completes instantiation without looking at the function parameter.
Jun 26 2012
On Tuesday, 26 June 2012 at 16:37:30 UTC, Timon Gehr wrote:On 06/26/2012 06:17 PM, Mehrdad wrote:Well the problem manifests itself in different ways, but would it be safe to say that void foo(auto ref int) { } should not cause problems either?void test1(T)(auto ref T) { } void test2() { int a = 5; test1!(int)(a); } Is there any reason this should fail?There is not. I suppose the compiler completes instantiation without looking at the function parameter.
Jun 26 2012
On Wednesday, June 27, 2012 02:54:49 Mehrdad wrote:On Tuesday, 26 June 2012 at 16:37:30 UTC, Timon Gehr wrote:That isn't legal. auto ref can only be used with templated functions. - Jonathan M DavisOn 06/26/2012 06:17 PM, Mehrdad wrote:Well the problem manifests itself in different ways, but would it be safe to say that void foo(auto ref int) { } should not cause problems either?void test1(T)(auto ref T) { } void test2() { int a = 5; test1!(int)(a); } Is there any reason this should fail?There is not. I suppose the compiler completes instantiation without looking at the function parameter.
Jun 26 2012
On Wednesday, 27 June 2012 at 03:54:12 UTC, Jonathan M Davis wrote:That isn't legal. auto ref can only be used with templated functions. - Jonathan M DavisThe trouble is, distinguishing between when it should be illegal seems like a blur to me. Consider all the cases like: - <Regular method> - <Mixin method> - <Template method> - Lambdas (in all forms) - Template class, <regular method> - Template class, <template method> - Regular class, <template method> - Regular class, template method, <mixin method> - Regular class, regular method, <mixin method> - Template class, regular method, <mixin method> - <Templates inside mixins> - yada yada It becomes a *nightmare* to try to get everything right, when you're dealing with templates and mixins. And you run into bugs like this. Why not just allow 'auto ref' for every function type?
Jun 26 2012
On Wednesday, June 27, 2012 06:03:12 Mehrdad wrote:On Wednesday, 27 June 2012 at 03:54:12 UTC, Jonathan M Davis wrote:And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version. If you pass it an rvalue, it generates a non-ref version. For it to work with a normal function, you would somehow have to make it work with only one version. The original idea was for it to work for all functions, but Walter said that it can't be done. So, it only works with templated functions. So, auto ref is pretty much a failure IMHO, since it was supposed to solve the problem of a single function being able to take both lvalues and rvalues efficiently. There has been some discussion of making it so that rvalues work with ref in order to fix that problem, but that hasn't been sorted out yet, since it has to be done in a way that avoids the problems that C++ has allowing const& to take lvalues. - Jonathan M DavisThat isn't legal. auto ref can only be used with templated functions. - Jonathan M DavisThe trouble is, distinguishing between when it should be illegal seems like a blur to me. Consider all the cases like: - <Regular method> - <Mixin method> - <Template method> - Lambdas (in all forms) - Template class, <regular method> - Template class, <template method> - Regular class, <template method> - Regular class, template method, <mixin method> - Regular class, regular method, <mixin method> - Template class, regular method, <mixin method> - <Templates inside mixins> - yada yada It becomes a *nightmare* to try to get everything right, when you're dealing with templates and mixins. And you run into bugs like this. Why not just allow 'auto ref' for every function type?
Jun 26 2012
On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value? - Treat it as though it were a templated parameter. Why does it make any difference here?
Jun 26 2012
On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?- Treat it as though it were a templated parameter. Why does it make any difference here?You can't just templatize functions. There are places where templated functions _can't_ be used. For instance, templated functions can't be virtual. And a templated function _can_ be used, then the programmer can just templatize it themselves, avoiding any possible issues caused by functions be automatically templatized. - Jonathan M Davis
Jun 26 2012
2012/6/27 Jonathan M Davis <jmdavisProg gmx.com>:On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwCiUAqg mail.gmail.com Kenji HaraOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?- Treat it as though it were a templated parameter. Why does it make any difference here?You can't just templatize functions. There are places where templated functions _can't_ be used. For instance, templated functions can't be virtual. And a templated function _can_ be used, then the programmer can just templatize it themselves, avoiding any possible issues caused by functions be automatically templatized. - Jonathan M Davis
Jun 26 2012
On 06/27/2012 07:27 AM, kenji hara wrote:2012/6/27 Jonathan M Davis<jmdavisProg gmx.com>:How does it deal with this case? auto ref id(auto ref arg){ return arg; }On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwCiUAqg mail.gmail.com Kenji HaraOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 27 2012
2012/6/27 Timon Gehr <timon.gehr gmx.ch>:On 06/27/2012 07:27 AM, kenji hara wrote:In this case, arg might bind rvalue allocated in the caller of id, so returning it with ref should be rejected statically. Kenji Hara2012/6/27 Jonathan M Davis<jmdavisProg gmx.com>:How does it deal with this case? auto ref id(auto ref arg){ return arg; }On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwCiUAqg mail.gmail.com Kenji HaraOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 27 2012
On 06/27/2012 01:12 PM, kenji hara wrote:2012/6/27 Timon Gehr<timon.gehr gmx.ch>:This is a quite severe limitation compared to how auto ref works today. As the return ref-ness is inferred and therefore the source code must be available, wouldn't it be a better option to decide lvalue/rvalue-ness at the call site? The compiler would just have to examine the first return statement in the function body.On 06/27/2012 07:27 AM, kenji hara wrote:In this case, arg might bind rvalue allocated in the caller of id, so returning it with ref should be rejected statically. Kenji Hara2012/6/27 Jonathan M Davis<jmdavisProg gmx.com>:How does it deal with this case? auto ref id(auto ref arg){ return arg; }On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwCiUAqg mail.gmail.com Kenji HaraOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 27 2012
On Wednesday, June 27, 2012 13:33:10 Timon Gehr wrote:On 06/27/2012 01:12 PM, kenji hara wrote:Considering that if you said that a parameter is auto ref, you're basically saying that it's being passed by value except that you'd like the compiler to avoid the copy if it can, I don't see why it's restrictive at all to make returning a ref to the parameter illegal. It would be like if you wanted to return a & to a const& parameter in C++, which would be a very bad idea. - Jonathan M Davis2012/6/27 Timon Gehr<timon.gehr gmx.ch>:This is a quite severe limitation compared to how auto ref works today. As the return ref-ness is inferred and therefore the source code must be available, wouldn't it be a better option to decide lvalue/rvalue-ness at the call site? The compiler would just have to examine the first return statement in the function body.On 06/27/2012 07:27 AM, kenji hara wrote:In this case, arg might bind rvalue allocated in the caller of id, so returning it with ref should be rejected statically. Kenji Hara2012/6/27 Jonathan M Davis<jmdavisProg gmx.com>:How does it deal with this case? auto ref id(auto ref arg){ return arg; }On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BG EtwCiUAqg mail.gmail.com Kenji HaraOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 27 2012
On 06/27/12 17:38, Jonathan M Davis wrote:On Wednesday, June 27, 2012 13:33:10 Timon Gehr wrote:That's not what auto-ref does. We already had this discussion. auto-ref lets you eg wrap other ref-taking functions; it matters for things like templates and variadics, where ParameterTypeTuple can't be used. You can also check if an argument was passed by reference with traits(isRef) and handle it differently. arturOn 06/27/2012 01:12 PM, kenji hara wrote:Considering that if you said that a parameter is auto ref, you're basically saying that it's being passed by value except that you'd like the compiler to avoid the copy if it can, I don't see why it's restrictive at all to make2012/6/27 Timon Gehr<timon.gehr gmx.ch>:This is a quite severe limitation compared to how auto ref works today. As the return ref-ness is inferred and therefore the source code must be available, wouldn't it be a better option to decide lvalue/rvalue-ness at the call site? The compiler would just have to examine the first return statement in the function body.On 06/27/2012 07:27 AM, kenji hara wrote:In this case, arg might bind rvalue allocated in the caller of id, so returning it with ref should be rejected statically. Kenji Hara2012/6/27 Jonathan M Davis<jmdavisProg gmx.com>:How does it deal with this case? auto ref id(auto ref arg){ return arg; }On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BG EtwCiUAqg mail.gmail.com Kenji HaraOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 27 2012
On 06/27/12 18:04, Artur Skawina wrote:On 06/27/12 17:38, Jonathan M Davis wrote:To clarify - /avoiding a copy/ is not the only, or even the main, use of this feature. Copy avoidance mostly matters for structs, and these cases should eventually be handled in a better way - but even when that will be done, auto-ref will still remain useful. arturOn Wednesday, June 27, 2012 13:33:10 Timon Gehr wrote: saying that it's being passed by value except that you'd like the compiler to avoid the copy if it can, I don't see why it's restrictive at all to makeThat's not what auto-ref does. We already had this discussion. auto-ref lets
Jun 27 2012
On 06/27/12 07:27, kenji hara wrote:2012/6/27 Jonathan M Davis <jmdavisProg gmx.com>:Please do not remove useful functionality in order to fix unrelated problems. "auto ref" isn't perfect, but it works well for some cases. A new "override ref" could work like you describe. arturOn Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwCiUAqg mail.gmail.comOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 27 2012
Artur Skawina:A new "override ref" could work like you describe.Introducing yet more modifiers and complexity should be done only if they are very useful. Bye, bearophile
Jun 27 2012
On Wednesday, June 27, 2012 14:27:08 kenji hara wrote:2012/6/27 Jonathan M Davis <jmdavisProg gmx.com>:If it can be done, I'm all for it. We really need a solution to this problem, and conceptually, auto ref was a good idea, it just hasn't worked thus far. - Jonathan M DavisOn Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwC iUAqg mail.gmail.comOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 26 2012
On Wednesday, June 27, 2012 16:39:12 Artur Skawina wrote:On 06/27/12 07:27, kenji hara wrote:What functionality are you talking about? What would you lose? - Jonathan M Davis2012/6/27 Jonathan M Davis <jmdavisProg gmx.com>:Please do not remove useful functionality in order to fix unrelated problems. "auto ref" isn't perfect, but it works well for some cases. A new "override ref" could work like you describe.On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:After considering about 'auto ref', I was concluded that is an inconsistency of current language spec and we cannot fix it correctly. http://d.puremagic.com/issues/show_bug.cgi?id=8204 Therefore, I have created a thread to suggest new 'auto ref' recently. http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEt wCiUAqg mail.gmail.comOn Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis wrote:That at least sounds like it would work. Walter may have a reason why it doesn't though, since he's the one that said that he didn't think that it was possible. Maybe he just didn't think of it, or maybe it causes some other problem that I can't think of.And how would that work? auto ref duplicates the function. If you pass it an lvalue, then it generates a ref version.Two solutions: - Turn 'auto ref' into 'ref', but simply have the compiler generate a copy for the caller if he wants to pass by value?
Jun 27 2012
On Wednesday, June 27, 2012 18:13:24 Artur Skawina wrote:On 06/27/12 18:04, Artur Skawina wrote:The _entire_ reason that auto ref on parameters was introduced in the first place was to have something comparable to C++'s const& which took both lvalues and rvalues efficiently without having to care which it was. That is the purpose of the feature. That's it. It may be that you've found other uses for it, but that's why it exists. The fact that it's implemented the way it is with templates is entirely an artifact of Walter having misunderstand what Andrei intended (which was for auto ref to somehow take both lvalues and rvalues with a single function definition while avoiding copying the lvalues). So, you may have an argument for why auto ref shouldn't be change, but if so, you're arguing for something that auto ref was never intended for. - Jonathan M DavisOn 06/27/12 17:38, Jonathan M Davis wrote:To clarify - /avoiding a copy/ is not the only, or even the main, use of this feature. Copy avoidance mostly matters for structs, and these cases should eventually be handled in a better way - but even when that will be done, auto-ref will still remain useful.On Wednesday, June 27, 2012 13:33:10 Timon Gehr wrote: saying that it's being passed by value except that you'd like the compiler to avoid the copy if it can, I don't see why it's restrictive at all to make>That's not what auto-ref does. We already had this discussion. auto-ref lets
Jun 27 2012