digitalmars.D.learn - Support implicit conversion between types
- ilya-stromberg (26/26) Sep 04 2013 I have some code like this:
- Namespace (7/33) Sep 04 2013 What's about:
- ilya-stromberg (4/9) Sep 04 2013 No, I wrote very simple example. I have 10 "from" types and a lot
- Kozzi (17/29) Sep 04 2013 So you can use templates, something like this:
- ilya-stromberg (5/6) Sep 04 2013 I know, it will work. But I really have **a lot of** different
- Adam D. Ruppe (13/15) Sep 04 2013 D does not support implicit struct construction.
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (6/15) Sep 04 2013 WHAT? :) It even new's one?
- Kapps (3/22) Sep 04 2013 http://dlang.org/function.html Under Typesafe Variadic Functions
- H. S. Teoh (9/33) Sep 04 2013 [...]
- Kapps (5/39) Sep 04 2013 It, in theory, doesn't allocate memory:
- H. S. Teoh (8/48) Sep 04 2013 That's even more scary. So the object implicitly constructed in this way
- H. S. Teoh (19/65) Sep 04 2013 [...]
I have some code like this: struct Foo { this(int i) { //do something useful } } void bar(Foo f) { //do something else } void main() { Foo f = 5;//works bar(f);//works bar(Foo(5));//works bar(5);//Error: function app.bar (Foo f) is not callable using argument types (int) } D can't implicitly convert type "int" to type "Foo", but constructor "Foo(int)" exists. Explicit conversion works fine. What should I do to support this convertion implicitly?
Sep 04 2013
On Wednesday, 4 September 2013 at 19:36:08 UTC, ilya-stromberg wrote:I have some code like this: struct Foo { this(int i) { //do something useful } } void bar(Foo f) { //do something else } void main() { Foo f = 5;//works bar(f);//works bar(Foo(5));//works bar(5);//Error: function app.bar (Foo f) is not callable using argument types (int) } D can't implicitly convert type "int" to type "Foo", but constructor "Foo(int)" exists. Explicit conversion works fine. What should I do to support this convertion implicitly?What's about: void bar(int i) { bar(Foo(i)); } ?
Sep 04 2013
On Wednesday, 4 September 2013 at 19:44:17 UTC, Namespace wrote:What's about: void bar(int i) { bar(Foo(i)); } ?No, I wrote very simple example. I have 10 "from" types and a lot of different "bar" functions. Your way will be more painful then explicit conversion.
Sep 04 2013
So you can use templates, something like this: bool isConvertableToFoo(T) { T i = void; return is(typeof(Foo(i)) == Foo); } void bar(T)(T i) if (is(T : Foo)) { //some code } void bar(T)(T i) if (!is(T : Foo) && isConvertableToFoo!T) { bar(Foo(i)); } I do not test it so it is maybe not completly correct :). On Wednesday, 4 September 2013 at 19:54:44 UTC, ilya-stromberg wrote:On Wednesday, 4 September 2013 at 19:44:17 UTC, Namespace wrote:What's about: void bar(int i) { bar(Foo(i)); } ?No, I wrote very simple example. I have 10 "from" types and a lot of different "bar" functions. Your way will be more painful then explicit conversion.
Sep 04 2013
On Wednesday, 4 September 2013 at 20:14:06 UTC, Kozzi wrote:So you can use templates, something like this:I know, it will work. But I really have **a lot of** different "bar" functions, so that way will be painful. So, the question is: what should I add to "Foo" struct to allow implicit conversions from "int" to "Foo"?
Sep 04 2013
On Wednesday, 4 September 2013 at 20:25:28 UTC, ilya-stromberg wrote:So, the question is: what should I add to "Foo" struct to allow implicit conversions from "int" to "Foo"?D does not support implicit struct construction. Interestingly though, it *does* support it for functions taking classes: class Foo { this(int i) {} } void foo(Foo f...) {} void main() { foo(10); } But there's nothing like it for structs.
Sep 04 2013
On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:D does not support implicit struct construction.That's what I knew.Interestingly though, it *does* support it for functions taking classes: class Foo { this(int i) {} } void foo(Foo f...) {} void main() { foo(10); }WHAT? :) It even new's one? But it works only for the ellipsis. I wonder why the discrepancy... Ali
Sep 04 2013
On Wednesday, 4 September 2013 at 21:14:26 UTC, Ali Çehreli wrote:On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:http://dlang.org/function.html Under Typesafe Variadic Functions -> For class objects.D does not support implicit struct construction.That's what I knew.Interestingly though, it *does* support it for functionstaking classes:class Foo { this(int i) {} } void foo(Foo f...) {} void main() { foo(10); }WHAT? :) It even new's one? But it works only for the ellipsis. I wonder why the discrepancy... Ali
Sep 04 2013
On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote:On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:[...] Whoa. I never knew about this! It's ... I don't know what to say. It seems to be a cool feature, but it's also ... so scary. Implicit new's just leaves a lump in my throat. Is this an actual, intentional feature??! T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...D does not support implicit struct construction.That's what I knew.Interestingly though, it *does* support it for functions taking classes: class Foo { this(int i) {} } void foo(Foo f...) {} void main() { foo(10); }WHAT? :) It even new's one? But it works only for the ellipsis. I wonder why the discrepancy...
Sep 04 2013
On Wednesday, 4 September 2013 at 23:00:07 UTC, H. S. Teoh wrote:On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote:It, in theory, doesn't allocate memory: "An implementation may construct the object or array instance on the stack. Therefore, it is an error to refer to that instance after the variadic function has returned"On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:[...] Whoa. I never knew about this! It's ... I don't know what to say. It seems to be a cool feature, but it's also ... so scary. Implicit new's just leaves a lump in my throat. Is this an actual, intentional feature??! TD does not support implicit struct construction.That's what I knew.Interestingly though, it *does* support it for functions taking classes: class Foo { this(int i) {} } void foo(Foo f...) {} void main() { foo(10); }WHAT? :) It even new's one? But it works only for the ellipsis. I wonder why the discrepancy...
Sep 04 2013
On Thu, Sep 05, 2013 at 01:04:30AM +0200, Kapps wrote:On Wednesday, 4 September 2013 at 23:00:07 UTC, H. S. Teoh wrote:That's even more scary. So the object implicitly constructed in this way is put on the *stack* instead of the heap, and becomes invalid after the function returns? That's just a minefield of pitfalls waiting to happen... T -- Curiosity kills the cat. Moral: don't be the cat.On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote:It, in theory, doesn't allocate memory: "An implementation may construct the object or array instance on the stack. Therefore, it is an error to refer to that instance after the variadic function has returned"On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:[...] Whoa. I never knew about this! It's ... I don't know what to say. It seems to be a cool feature, but it's also ... so scary. Implicit new's just leaves a lump in my throat. Is this an actual, intentional feature??! TD does not support implicit struct construction.That's what I knew.Interestingly though, it *does* support it for functions taking classes: class Foo { this(int i) {} } void foo(Foo f...) {} void main() { foo(10); }WHAT? :) It even new's one? But it works only for the ellipsis. I wonder why the discrepancy...
Sep 04 2013
On Wed, Sep 04, 2013 at 04:07:28PM -0700, H. S. Teoh wrote:On Thu, Sep 05, 2013 at 01:04:30AM +0200, Kapps wrote:[...] Hmm. I experimented with this "feature", and found some interesting quirks: void foo(Foo f...) {...} can only be called with the same arguments as Foo's ctor, and 'f' inside the function body refers to the *single* class instance implicitly constructed. The object is actually allocated on the heap, even though the class reference is on the stack (perfectly normal). So this syntax appears to be some kind of surrogate ctor syntax, in which foo() acts as a surrogate ctor, getting the constructed object as a parameter and possibly modifying it or returning something else in its place. I can see where this might be useful, but I'm confused by the choice of syntax. This isn't a true variadic function at all; it's a ctor wrapper? Why was this syntax chosen? I'm really puzzled now. T -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley TarotOn Wednesday, 4 September 2013 at 23:00:07 UTC, H. S. Teoh wrote:That's even more scary. So the object implicitly constructed in this way is put on the *stack* instead of the heap, and becomes invalid after the function returns? That's just a minefield of pitfalls waiting to happen...On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote:It, in theory, doesn't allocate memory: "An implementation may construct the object or array instance on the stack. Therefore, it is an error to refer to that instance after the variadic function has returned"On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:[...] Whoa. I never knew about this! It's ... I don't know what to say. It seems to be a cool feature, but it's also ... so scary. Implicit new's just leaves a lump in my throat. Is this an actual, intentional feature??! TD does not support implicit struct construction.That's what I knew.Interestingly though, it *does* support it for functions taking classes: class Foo { this(int i) {} } void foo(Foo f...) {} void main() { foo(10); }WHAT? :) It even new's one? But it works only for the ellipsis. I wonder why the discrepancy...
Sep 04 2013