Preventing implicit conversion

Is there an elegant way of avoiding implicit conversion to int when you're using shorter types?

Re: Preventing implicit conversion

V Wed, 04 Nov 2015 14:27:45 + ixid via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> napsáno: > Is there an elegant way of avoiding implicit conversion to int > when you're using shorter types? http://dlang.org/phobos/std_typecons.html#.Typedef

Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 17:26:04 UTC, Daniel Kozak wrote: V Wed, 04 Nov 2015 14:27:45 + ixid via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> napsáno: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? http://dla

Re: Implicit conversion rules

On Wednesday, 21 October 2015 at 22:49:16 UTC, Marco Leise wrote: God forbid anyone implement such nonsense into D ! That would be the last thing we need Slight nitpick, but what I suggested for our hypothetical situation was only to apply for auto, once variable was assigned to auto and

Re: Implicit conversion rules

On Wednesday, 21 October 2015 at 19:49:35 UTC, Ali Çehreli wrote: On 10/21/2015 12:37 PM, Sigg wrote: > cause at least few more "fun" side effects. One of those side effects would be function calls binding silently to another overload: void foo(bool){/* ... */} void foo(int) {/* ... */}

Implicit conversion rules

I started reading "The D programming Language" earlier, and came to the "2.3.3 Typing of Numeric Operators" section which claims that "if at least one participant has type ulong, the other is implicitly converted to ulong prior to the application and the result has type ulong.". Now I

Re: Implicit conversion rules

On 10/21/2015 12:37 PM, Sigg wrote: > cause at least few more "fun" side effects. One of those side effects would be function calls binding silently to another overload: void foo(bool){/* ... */} void foo(int) {/* ... */} auto a = 0; // If the type were deduced by the value, foo(a);

Re: Implicit conversion rules

On Wednesday, October 21, 2015 07:53 PM, Sigg wrote: > void func() { > int a = -10; > ulong b = 0; > ulong c = a + b; > writefln("%s", c); > } > > out: 18446744073709551574 > > But shouldn't declaring c as auto force compiler to go extra step >

Re: Implicit conversion rules

something like this would not be implemented since it would ignore implicit conversion table and prolly cause at least few more "fun" side effects. std.bigint and core.checkedint may be of interest to you, if you prefer safer operations over faster ones. http://dlang.org/phobos/std_b

Re: Implicit conversion rules

Am Wed, 21 Oct 2015 12:49:35 -0700 schrieb Ali Çehreli : > On 10/21/2015 12:37 PM, Sigg wrote: > > > cause at least few more "fun" side effects. > > One of those side effects would be function calls binding silently to > another overload: > > void foo(bool){/* ... */} >

Re: Implicit conversion rules

On Wednesday, 21 October 2015 at 22:49:16 UTC, Marco Leise wrote: Am Wed, 21 Oct 2015 12:49:35 -0700 schrieb Ali Çehreli : On 10/21/2015 12:37 PM, Sigg wrote: > cause at least few more "fun" side effects. One of those side effects would be function calls binding

Re: Implicit conversion with ctor like C++

I made a mistake it's more like: //Sample class class CClass { this(string MyValue){...} } //Called function void MyFunction(CClass MyClass){} void main() { MyFunction("Hello World!"); //Failed : MyFunction not callable... }

Re: Implicit conversion with ctor like C++

On Tuesday, 8 September 2015 at 19:23:47 UTC, Pierre wrote: Hi everybody, I would like to use implicit conversion like this: //Sample class class MyClass { this(string MyValue){...} } //Called function void MyFunction(Foo MyFoo){} void main() { MyFunction("Hello World!")

Re: Implicit conversion with ctor like C++

OK that's very clear thank you for the answer.

Implicit conversion with ctor like C++

Hi everybody, I would like to use implicit conversion like this: //Sample class class MyClass { this(string MyValue){...} } //Called function void MyFunction(Foo MyFoo){} void main() { MyFunction("Hello World!"); //Failed : MyFunction not callable... } I saw in forum

Re: Implicit conversion in constructor

On Saturday, 18 July 2015 at 02:23:26 UTC, rcorre wrote: Is there any reason why implicit conversion from Foo to Thing is permitted in a regular method but not in a constructor? In the constructor, you are supposed to be constructing things, so the first assignment of structs is actually

Re: Implicit conversion in constructor

On Saturday, 18 July 2015 at 02:28:09 UTC, tcak wrote: I even am not sure how in the world it allows implicit conversion from class to struct in fine at all. Given: struct Foo { T x; alias x this; } Any time you do Foo foo; foo.something = whatever; // or foo = whatever

Implicit conversion in constructor

Is there any reason why implicit conversion from Foo to Thing is permitted in a regular method but not in a constructor? Trying to figure out whether this is a bug or some sort of constructor-specific safety precaution. struct Thing { Foo foo; alias foo this; } class Foo { } class Bar

Re: Implicit conversion in constructor

On Saturday, 18 July 2015 at 02:28:09 UTC, tcak wrote: I even am not sure how in the world it allows implicit conversion from class to struct in fine at all. The 'alias this' in the struct permits implicit conversion. I _think_ that is intended behavior, though I admit I'm not actually sure

Re: Implicit conversion in constructor

On Saturday, 18 July 2015 at 02:23:26 UTC, rcorre wrote: Is there any reason why implicit conversion from Foo to Thing is permitted in a regular method but not in a constructor? Trying to figure out whether this is a bug or some sort of constructor-specific safety precaution. struct Thing

Implicit conversion from null in custom type

I'm trying to write a type which (to some extent) emulates built-in AAs. One thing I'm having trouble with is null function parameters: void fun(S s) {} void main() { fun(null); } How can S implement implicit conversion from null? I've already tried alias this and a constructor taking

Re: Implicit conversion from null in custom type

IIRC the rationale to ignore implicit conversions was to simplify function overloading rules.

Re: Implicit conversion from null in custom type

parameters: void fun(S s) {} void main() { fun(null); } How can S implement implicit conversion from null? I've already tried alias this and a constructor taking typeof(null).

Re: Implicit conversion from null in custom type

On Thursday, 28 May 2015 at 12:37:52 UTC, Andrea Fontana wrote: What's the problem with ctor taking typeof(null)? I've just used it, maybe I missed something? It doesn't work: // test.d / struct S { this(typeof(null) p) {} } void fun(S s) {} void main() { fun(null); }

Re: Implicit conversion from null in custom type

On Thursday, 28 May 2015 at 11:37:34 UTC, Kagamin wrote: IIRC the rationale to ignore implicit conversions was to simplify function overloading rules. Isn't this a requirement for making AAs user types anyway?

Re: Implicit conversion from null in custom type

void fun(typeof(null)) { } ? On Thursday, 28 May 2015 at 13:06:27 UTC, Vladimir Panteleev wrote: On Thursday, 28 May 2015 at 12:37:52 UTC, Andrea Fontana wrote: What's the problem with ctor taking typeof(null)? I've just used it, maybe I missed something? It doesn't work: //

Re: Implicit conversion from null in custom type

On Thursday, 28 May 2015 at 13:12:18 UTC, Andrea Fontana wrote: void fun(typeof(null)) { } You don't have to do that for built-in arrays though. BTW I literally just wrote a slide on this for my Friday talk before reading this thread. I think D could have some implicit struct constructors,

Re: Implicit conversion from null in custom type

On Thursday, 28 May 2015 at 13:46:52 UTC, Meta wrote: What about defining a static `nil` value for S? Might as well just use S.init. Again, doesn't help with creating a drop-in replacement.

Re: Implicit conversion from null in custom type

On Thursday, 28 May 2015 at 13:12:18 UTC, Andrea Fontana wrote: void fun(typeof(null)) { } ? That doesn't help with creating a drop-in replacement for an AA (or any built-in type implicitly convertible from null).

Re: Implicit conversion from null in custom type

On Thursday, 28 May 2015 at 11:19:39 UTC, Vladimir Panteleev wrote: I'm trying to write a type which (to some extent) emulates built-in AAs. One thing I'm having trouble with is null function parameters: void fun(S s) {} void main() { fun(null); } How can S implement implicit conversion from

Re: Implicit conversion from null in custom type

as init, except you have control over it and the struct doesn't default to it. We really do need some kind of implicit conversion facility when passing to and returning from functions, though.

Re: Implicit conversion error

On Thursday, 30 April 2015 at 22:24:15 UTC, bearophile wrote: Paul: When compiled on a 64 bit machine, this line int r = uniform(0, mobs.length); .length returns a size_t, and 0 is an int. uniform() probably decides to unify those types to a size_t. A size_t is 32 bit on 32 bit machines

Implicit conversion error

When compiled on a 64 bit machine, this line int r = uniform(0, mobs.length); gives me an error: Error: cannot implicitly convert expression (uniform(0, mobs.length)) of type ulong to int but it compiles ok on a 32 bit machine. I thought it was the expression on the righthand side returning

Re: Implicit conversion error

Paul: When compiled on a 64 bit machine, this line int r = uniform(0, mobs.length); .length returns a size_t, and 0 is an int. uniform() probably decides to unify those types to a size_t. A size_t is 32 bit on 32 bit machines and 64 bits on 64 bit machines. But D int is always a 32 bit

Testing implicit conversion to template instance with is() expression

Should this work? struct V(string s) { } struct S(int U) { V!xyz x; alias x this; } void main() { S!10 a; static assert(is(a : V!Args, Args...)); } With DMD Git master, the static assert() fails. Should it? Am I doing something wrong?

Re: Testing implicit conversion to template instance with is() expression

On 03/15/2015 08:47 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Should this work? struct V(string s) { } struct S(int U) { V!xyz x; alias x this; } void main() { S!10 a; static assert(is(a : V!Args,

Re: Testing implicit conversion to template instance with is() expression

On Sunday, 15 March 2015 at 16:44:14 UTC, Ali Çehreli wrote: On 03/15/2015 08:47 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Should this work? struct V(string s) { } struct S(int U) { V!xyz x; alias x this; } void main() {

Re: Testing implicit conversion to template instance with is() expression

https://issues.dlang.org/show_bug.cgi?id=14286 In the meantime, does someone know of a suitable workaround?

Re: Testing implicit conversion to template instance with is() expression

On Sunday, 15 March 2015 at 16:53:34 UTC, Marc Schütz wrote: On Sunday, 15 March 2015 at 16:44:14 UTC, Ali Çehreli wrote: On 03/15/2015 08:47 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Should this work? struct V(string s) { } struct S(int U) { V!xyz

Re: Testing implicit conversion to template instance with is() expression

On Sunday, 15 March 2015 at 18:53:33 UTC, Nicolas Sicard wrote: Can be reduced to: struct Foo(int i) {} alias Foo1 = Foo!1; static assert(is(Foo!2 == Foo1!T, T...)); // OK I think it's another bug. Right, I've filed another report: https://issues.dlang.org/show_bug.cgi?id=14290

Re: Testing implicit conversion to template instance with is() expression

On Sunday, 15 March 2015 at 17:03:42 UTC, Marc Schütz wrote: https://issues.dlang.org/show_bug.cgi?id=14286 In the meantime, does someone know of a suitable workaround? I found the following workaround. Not beautiful, but it works: enum isValue(alias T) = __traits(compiles, typeof(T));

Re: Testing implicit conversion to template instance with is() expression

On Sunday, 15 March 2015 at 18:33:32 UTC, Marc Schütz wrote: On Sunday, 15 March 2015 at 17:03:42 UTC, Marc Schütz wrote: https://issues.dlang.org/show_bug.cgi?id=14286 In the meantime, does someone know of a suitable workaround? I found the following workaround. Not beautiful, but it works:

Re: implicit conversion

Sorry should add this is on 2.066.0-rc2 and it used to work on 2.064. Cheers, uri On Tuesday, 12 August 2014 at 06:21:19 UTC, uri wrote: Hi, I'm trying to allow implicit conversions for my own type happening. I have the following: import std.math; import std.traits; struct S(T)

implicit conversion

Hi, I'm trying to allow implicit conversions for my own type happening. I have the following: import std.math; import std.traits; struct S(T) if(isFloatingPoint!T) { T val; alias val this; } void main() { auto s = S!float(); assert(isNaN(s)); s = 10.0;

Re: implicit conversion

type. You can open a bug report - https://issues.dlang.org - and mark it as a regression, and it might get changed, but the reality of the matter is that templates don't tend to play well with implicit conversions. It's _far_ too easy to allow something in due to an implicit conversion

Re: implicit conversion

_far_ too easy to allow something in due to an implicit conversion and then have it not actually work, because the value is never actually converted. In general, I would strongly advise against attempting to give types implicit conversions precisely because they tend to not play nicely

Re: implicit conversion

://issues.dlang.org - and mark it as a regression, and it might get changed, but the reality of the matter is that templates don't tend to play well with implicit conversions. It's _far_ too easy to allow something in due to an implicit conversion and then have it not actually work, because the value is never

Re: implicit conversion

. It's _far_ too easy to allow something in due to an implicit conversion and then have it not actually work, because the value is never actually converted. In general, I would strongly advise against attempting to give types implicit conversions precisely because they tend to not play

Re: implicit conversion

On Tuesday, 12 August 2014 at 14:26:46 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: AFAIK, the only time that the implicit conversion would take place is when the type is being used in a situation where it doesn't work directly but where the aliased type is used. In that case

Re: implicit conversion

. If you're dealing with a template which doesn't accept implicit conversions (e.g. isNaN), and the implicit conversion were tested after the actual type failed, and the template was then instantiated with the implicitly converted type, then maybe that could work, but that's not how it works now

Re: implicit conversion

this is a very powerful tool that we haven't fully leveraged yet. Not only it allows for implicit conversion to native types (which makes it very useful for transparent type wrapping and user-defined numeric types that are on par with built-in types), it also allows for things like transparent safe

Re: implicit conversion

to write a template constraint which passes due to the implicit conversion (even if an implicit conversion wasn't explicitly checked for) but then have the function fail to work properly because the implicit conversion never actually takes place within the function (and if the template

Re: implicit conversion

. Allowing implicit conversions makes the problem much worse IMHO. It makes it far too easy to write a template constraint which passes due to the implicit conversion (even if an implicit conversion wasn't explicitly checked for) but then have the function fail to work properly because

Re: implicit conversion

wrong, that I don't it justifies blaming alias this for problems. Allowing implicit conversions makes the problem much worse IMHO. It makes it far too easy to write a template constraint which passes due to the implicit conversion (even if an implicit conversion wasn't explicitly checked

Implicit conversion from a base/array type

Is there a way to implicitly convert *FROM* a base type? I have an implicit conversion to a base type (float[2]) in a struct, but now I'd like to be able to implicitly convert from a base type (in this case a float[2]) to a struct. Is this even allowed? Is it incorrect or unsafe? I'm still

Re: Implicit conversion from a base/array type

I tried something similar to (check first answer): http://stackoverflow.com/questions/121162/what-does-the-explicit-keyword-in-c-mean but I can't get it to work. But then again... I'm just starting with D. It seems not to be supported:

Re: Implicit conversion from a base/array type

On Saturday, 1 February 2014 at 20:26:27 UTC, alexhairyman wrote: Is there a way to implicitly convert *FROM* a base type? I have an implicit conversion to a base type (float[2]) in a struct, but now I'd like to be able to implicitly convert from a base type (in this case a float[2

Re: Implicit conversion from a base/array type

On Sat, 01 Feb 2014 21:23:07 +, TheFlyingFiddle wrote: On Saturday, 1 February 2014 at 20:26:27 UTC, alexhairyman wrote: Is there a way to implicitly convert *FROM* a base type? I have an implicit conversion to a base type (float[2]) in a struct, but now I'd like to be able to implicitly

Re: Implicit conversion from a base/array type

On Sat, 01 Feb 2014 21:18:12 +, Martijn Pot wrote: I tried something similar to (check first answer): http://stackoverflow.com/questions/121162/what-does-the-explicit- keyword-in-c-mean but I can't get it to work. But then again... I'm just starting with D. It seems not to be

Support implicit conversion between types

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

Re: Support implicit conversion between types

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.

Re: Support implicit conversion between types

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

Re: Support implicit conversion between types

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

Re: Support implicit conversion between types

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:

Re: Support implicit conversion between types

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); }

Re: Support implicit conversion between types

On Wednesday, 4 September 2013 at 21:14:26 UTC, Ali Çehreli wrote: 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)

Re: Support implicit conversion between types

On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote: 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

Re: Support implicit conversion between types

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: On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote: On 09/04/2013 01:46 PM, Adam D. Ruppe wrote: D does not support implicit struct construction. That's what

Re: Support implicit conversion between types

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: 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: On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:

Implicit conversion to bool, and other conversions.

The operator overloading page in the Language Reference and the operator overloading discussion in TDLP say different things about T opCast(bool)() if(is(T==bool)) and experimentally it seems that in any context where a bool is expected and x occurs (where x is a struct with such an opCast

Re: Implicit conversion to bool, and other conversions.

On 08/16/2013 02:18 PM, Carl Sturtivant wrote: The operator overloading page in the Language Reference and the operator overloading discussion in TDLP say different things about T opCast(bool)() if(is(T==bool)) The current syntax is the following: bool opCast(T : bool)() const and

Re: Implicit conversion to bool, and other conversions.

, int to double and so forth)? opCast is only ever for explicit conversions. alias this is used for implicit conversions. Whether things get confusing is that there are places where the compiler inserts casts for you, so it _looks_ like there's an implicit conversion, but there isn't really

Re: Implicit conversion to bool, and other conversions.

On Friday, August 16, 2013 14:35:53 Ali Çehreli wrote: On 08/16/2013 02:18 PM, Carl Sturtivant wrote: The operator overloading page in the Language Reference and the operator overloading discussion in TDLP say different things about T opCast(bool)() if(is(T==bool)) The current syntax

Re: Implicit conversion to bool, and other conversions.

like there's an implicit conversion, but there isn't really. In particular, cast(bool) is inserted in the conditions of if statements, loops, ternary operators, and assertions. So, if you have something like if(a) {} it becomes if(cast(bool)a) {} So, if you want to use a struct in a condition

Re: Implicit conversion to bool, and other conversions.

like there's an implicit conversion, but there isn't really. In particular, cast(bool) is inserted in the conditions of if statements, loops, ternary operators, and assertions. So, if you have something like if(a) {} it becomes if(cast(bool)a) {} So, if you want to use a struct in a condition

Re: implicit conversion to alias this

I'm fine that the assignment to C is verboten. I'd disallow the  first assignments to and would like to know, why they are kept. OK, now I get it. I'm not sure why they're allowed, either; I guess that it's just because it's written with assignment syntax. On second thought, it might be

Re: implicit conversion to alias this

On Monday, June 25, 2012 22:06:20 Tobias Pankrath wrote: - struct A { bool a; alias a this; } struct B { int b; alias b this; } A a = false; // works B b = 12; // works struct C { A aa; B ab; } C c = { false, 12 }; // does not work, because the implicit conversion does

Re: implicit conversion to alias this

I'm fine that the assignment to C is verboten. I'd disallow the  first assignments to and would like to know, why they are kept. OK, now I get it. I'm not sure why they're allowed, either; I guess that it's just because it's written with assignment syntax. On second thought, it might be

Re: implicit conversion to alias this

On Monday, 25 June 2012 at 20:06:21 UTC, Tobias Pankrath wrote: - struct A { bool a; alias a this; } struct B { int b; alias b this; } A a = false; // works B b = 12; // works struct C { A aa; B ab; } C c = { false, 12 }; // does not work, because the implicit conversion does

Re: implicit conversion to alias this

}; // does not work, because the implicit conversion does not happen. - What is the reason to allow the first two assignments? Isn't it just another implicit conversion that shouldn't be allowed? The compiler isn't smart enough to realize that you're trying to use an implicit conversion

implicit conversion to alias this

- struct A { bool a; alias a this; } struct B { int b; alias b this; } A a = false; // works B b = 12; // works struct C { A aa; B ab; } C c = { false, 12 }; // does not work, because the implicit conversion does not happen. - What is the reason to allow the first two

Implicit conversion from class in parent class fails?

Why work this: [code] class Foo { } class Bar : Foo { } class Quatz : Bar { } void foo(Foo f) { } void main() { Foo f = new Foo(); Foo f2; foo(f); foo(f2); Bar b = new Bar(); Bar b2; foo(b); foo(b2);

Re: Implicit conversion from class in parent class fails?

On Sat, Jun 16, 2012 at 11:52 AM, Namespace rswhi...@googlemail.com wrote: Why work this: [code] class Foo { } class Bar : Foo { } class Quatz : Bar { } void foo(Foo f) { } void main() {        Foo f = new Foo();        Foo f2;        foo(f);        foo(f2);        Bar b = new

Re: Implicit conversion from class in parent class fails?

On 06/16/2012 11:55 AM, Andrew Wiley wrote: On Sat, Jun 16, 2012 at 11:52 AM, Namespacerswhi...@googlemail.com wrote: Why work this: [code] class Foo { } class Bar : Foo { } class Quatz : Bar { } void foo(Foo f) { } void main() { Foo f = new Foo(); Foo f2; foo(f);

Re: Implicit conversion of unique objects to mutable and immutable

On Tue, 21 Jun 2011 20:31:19 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On 2011-06-21 16:50, Ali Çehreli wrote: On Tue, 21 Jun 2011 23:02:43 +, Jonathan M Davis wrote: On 2011-06-21 15:25, Ali Çehreli wrote: (Note: I have a feeling that this must be related to the old 'unique'

Re: Implicit conversion of unique objects to mutable and immutable

On Wed, 22 Jun 2011 00:02:55 +, Ali Çehreli wrote: I wonder whether a UniqueRef object could be returned, which could allow a single casting of its data to mutable or immutable at the call site. Further casts could throw, but that would be a runtime solution. :-/ Further casts should

Re: Implicit conversion of unique objects to mutable and immutable

On Wed, 22 Jun 2011 15:58:02 +, Timon Gehr wrote: On Wed, 22 Jun 2011 00:02:55 +, Ali Çehreli wrote: I wonder whether a UniqueRef object could be returned, which could allow a single casting of its data to mutable or immutable at the call site. Further casts could throw, but that

Re: Implicit conversion of unique objects to mutable and immutable

Ali Çehreli: char[] result = foo(); string immutable_result = assumeUnique(result); But that's the wrong thing to do, as foo() may be changed in the future to return a non-unique result. I think assumeUnique is meant to be used inside foo(), at its end. Somewhere in Bugzilla (I

Re: Implicit conversion of unique objects to mutable and immutable

On 2011-06-21 15:25, Ali Çehreli wrote: (Note: I have a feeling that this must be related to the old 'unique' discussions, which I had somehow managed to stay out of. If so, I apologize for repeating an old story.) It is most useful for a function to return the most mutable type unless

Re: Implicit conversion of unique objects to mutable and immutable

On Tue, 21 Jun 2011 23:02:43 +, Jonathan M Davis wrote: On 2011-06-21 15:25, Ali Çehreli wrote: (Note: I have a feeling that this must be related to the old 'unique' discussions, which I had somehow managed to stay out of. If so, I apologize for repeating an old story.) It is most

Re: Implicit conversion of unique objects to mutable and immutable

On Tue, 21 Jun 2011 19:04:11 -0400, bearophile wrote: Ali Çehreli: char[] result = foo(); string immutable_result = assumeUnique(result); But that's the wrong thing to do, as foo() may be changed in the future to return a non-unique result. I think assumeUnique is meant to be

Re: Implicit conversion of unique objects to mutable and immutable

On 2011-06-21 16:50, Ali Çehreli wrote: On Tue, 21 Jun 2011 23:02:43 +, Jonathan M Davis wrote: On 2011-06-21 15:25, Ali Çehreli wrote: (Note: I have a feeling that this must be related to the old 'unique' discussions, which I had somehow managed to stay out of. If so, I apologize for

Re: Implicit conversion of unique objects to mutable and immutable

On Wed, 22 Jun 2011 00:31:19 +, Jonathan M Davis wrote: As I said, in Phobos, when a new string must be allocated, the type returned is generally string (so it's immutable), whereas if the result of the function is likely to be slice of the string passed in, then the function is templated

Re: Implicit conversion of unique objects to mutable and immutable

On Wed, 22 Jun 2011 00:02:55 +, Ali Çehreli wrote: I wonder whether a UniqueRef object could be returned, which could allow a single casting of its data to mutable or immutable at the call site. Further casts could throw, but that would be a runtime solution. :-/ An extremely rough

Implicit conversion from array of class to array of interface

(D 2.033) I have a need to do something like this code: interface I {} class C : I {} class D : I {} void f(I[]) {} void f(bool) {} void g(T)(T param) { f(param); } int main() { bool b; C[] c; D[] d; g(b); g(c); g(d); return 0; }

Re: Implicit conversion from array of class to array of interface

On Sun, 13 Dec 2009 03:22:31 -0500, Phil Deets pjdee...@gmail.com wrote: (D 2.033) I have a need to do something like this code: interface I {} class C : I {} class D : I {} void f(I[]) {} void f(bool) {} void g(T)(T param) { f(param); } int main() { bool b; C[] c;

Re: Implicit conversion from array of class to array of interface

On Sun, 13 Dec 2009 04:16:19 -0500, Frank Benoit keinfarb...@googlemail.com wrote: casting an array of class references to an array of interface references (or vice versa) will not work at runtime. Your program will crash. This is because if the invisible pointer correction that is done if

Re: Implicit conversion from array of class to array of interface

On Sun, 13 Dec 2009 04:08:19 -0500, Phil Deets pjdee...@gmail.com wrote: I found another workaround which doesn't require a bunch of extra overloads. I'll probably update it to use that template someone wrote in that thread about static duck-typing. I looked up this post. It was: Re:

<    1   2