On 2013-09-07, 15:19, ilya-stromberg wrote:
On Saturday, 7 September 2013 at 13:02:39 UTC, Simen Kjaeraas wrote:
It's a bit weird in D though, as operators are instance methods, and
opImplicitRightCast (or opImplicitCastFrom, which is the name used in
discussions before, see WalterAndrei.pdf
On 2013-09-06, 19:12, Dmitry Olshansky wrote:
06-Sep-2013 21:05, H. S. Teoh пишет:
On Fri, Sep 06, 2013 at 05:14:48PM +0200, ilya-stromberg wrote:
On Friday, 6 September 2013 at 14:26:17 UTC, H. S. Teoh wrote:
I thought the usual D idiom was to write factorial(5) and
factorial(BigInt(5)) and
On 2013-09-06, 15:57, ilya-stromberg wrote:
On Friday, 6 September 2013 at 13:39:20 UTC, deadalnix wrote:
You don't want a keyword for that. Something obscure and ugly is
required.
C# have operator overloading for this.
We can use, for example, opImplicitRightCast
struct Foo
{
Foo
On Saturday, 7 September 2013 at 13:02:39 UTC, Simen Kjaeraas
wrote:
It's a bit weird in D though, as operators are instance
methods, and
opImplicitRightCast (or opImplicitCastFrom, which is the name
used in
discussions before, see WalterAndrei.pdf from back when
dinosaurs roamed the
earth)
On Friday, 6 September 2013 at 13:15:21 UTC, Benjamin Thaut wrote:
Am 06.09.2013 15:01, schrieb Dicebot:
Probably. But what is the gain? `foo(Foo(5))` looks better
than `foo(5)`
to me in every possible way.
For example, use case that justifies operator overloading
(despite the
danger) in my
On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
Do you have any plans to support implicit conversion between
types?
I have some code like this:
struct Foo
{
this(int i)
{
//do something useful
}
}
void bar(Foo f)
{
//do
On Saturday, 7 September 2013 at 19:37:28 UTC, Maxim Fomin wrote:
Actually D has this feature for classes:
class A
{
this(int) {}
}
void foo(A a ...) {}
void main()
{
foo(5);
}
This compiles and runs as expected. By the way, the code was
fixed recently - before 2.063 this
I understand and support Kenjis request (linked in this thread)
in the no casting, though version.
And I find C++ or C# or Foo2k has this! a very troublesome
approach and measure.
Whatever feature is introducing inconsistencies is almost never
worth it.
We do have explicit conversion. If
Do you have any plans to 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
Am 06.09.2013 12:33, schrieb ilya-stromberg:
Do you have any plans to 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 =
On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
Do you have any plans to support implicit conversion between
types?
Implicit conversions open up a whole can of worms for the sake of
a small amount of convenience.
I'm not sure it's a fair trade.
On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander
wrote:
Implicit conversions open up a whole can of worms for the sake
of a small amount of convenience.
I'm not sure it's a fair trade.
Agreed. It was quite common source of troubles in my C++ days and
have never offered much
Am 06.09.2013 13:27, schrieb Dicebot:
On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander wrote:
Implicit conversions open up a whole can of worms for the sake of a
small amount of convenience.
I'm not sure it's a fair trade.
Agreed. It was quite common source of troubles in my C++
On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander
wrote:
On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg
wrote:
Do you have any plans to support implicit conversion between
types?
Implicit conversions open up a whole can of worms for the sake
of a small amount of
Am 06.09.2013 13:44, schrieb deadalnix:
On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander wrote:
On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
Do you have any plans to support implicit conversion between types?
Implicit conversions open up a whole can of worms
On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut wrote:
Am 06.09.2013 13:27, schrieb Dicebot:
On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander
wrote:
Implicit conversions open up a whole can of worms for the
sake of a
small amount of convenience.
I'm not sure it's a
On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut wrote:
Its only a source of troubles in C++ because it is the default
behavior. But if you design a library it can make the usage of
your api easier and also you have a few more options to stay
backwards compatible with your old api.
On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut wrote:
Its only a source of troubles in C++ because it is the default
behavior. But if you design a library it can make the usage of
your api easier and also you have a few more options to stay
backwards compatible with your old api.
Am 06.09.2013 15:01, schrieb Dicebot:
On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut wrote:
Its only a source of troubles in C++ because it is the default
behavior. But if you design a library it can make the usage of your
api easier and also you have a few more options to stay
On Friday, 6 September 2013 at 13:01:14 UTC, Dicebot wrote:
For example, use case that justifies operator overloading
(despite the danger) in my eyes is ability to replace built-in
types with custom ones. What is the similar rationale for
implicit conversion?
For exaple, for generic code:
T
On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
Do you have any plans to support implicit conversion between
types?
I have some code like this:
struct Foo
{
this(int i)
{
//do something useful
}
}
void bar(Foo f)
{
//do
On Friday, 6 September 2013 at 13:25:37 UTC, Flamaros wrote:
It's difficult to never forget the explicit keyword in c++,
and this little mistake can make you loose a lot of time.
I prefer to only have explicit conversions with cast or
constructors calls, that all make the code easier to
On Friday, 6 September 2013 at 13:21:44 UTC, ilya-stromberg wrote:
On Friday, 6 September 2013 at 13:01:14 UTC, Dicebot wrote:
For example, use case that justifies operator overloading
(despite the danger) in my eyes is ability to replace built-in
types with custom ones. What is the similar
On Friday, 6 September 2013 at 13:31:41 UTC, ilya-stromberg wrote:
On Friday, 6 September 2013 at 13:25:37 UTC, Flamaros wrote:
It's difficult to never forget the explicit keyword in c++,
and this little mistake can make you loose a lot of time.
I prefer to only have explicit conversions with
On Friday, 6 September 2013 at 13:01:14 UTC, Dicebot wrote:
On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut
wrote:
Its only a source of troubles in C++ because it is the default
behavior. But if you design a library it can make the usage of
your api easier and also you have a few
On Friday, 6 September 2013 at 13:30:26 UTC, Dicebot wrote:
So, what essentially is needed, is ability to implicitly
convert literals of built-in types to user types, not any
possible implicit conversion?
I think allowing it with such restrictions can be reasonably
clean.
Yes, the ability
On Friday, 6 September 2013 at 13:39:20 UTC, deadalnix wrote:
You don't want a keyword for that. Something obscure and ugly
is required.
C# have operator overloading for this.
We can use, for example, opImplicitRightCast
struct Foo
{
Foo opImplicitRightCast(T)(T from);
}
On Fri, Sep 06, 2013 at 03:21:42PM +0200, ilya-stromberg wrote:
On Friday, 6 September 2013 at 13:01:14 UTC, Dicebot wrote:
For example, use case that justifies operator overloading (despite
the danger) in my eyes is ability to replace built-in types with
custom ones. What is the similar
On Friday, 6 September 2013 at 13:50:25 UTC, ilya-stromberg wrote:
On Friday, 6 September 2013 at 13:30:26 UTC, Dicebot wrote:
So, what essentially is needed, is ability to implicitly
convert literals of built-in types to user types, not any
possible implicit conversion?
I think allowing it
On Friday, 6 September 2013 at 14:26:17 UTC, H. S. Teoh wrote:
I thought the usual D idiom was to write factorial(5) and
factorial(BigInt(5)) and let the compiler figure out which
template
instance you wanted?
Yes, but it isn't always possible.
It can be critical for more complex cases,
On Friday, 6 September 2013 at 15:14:50 UTC, ilya-stromberg wrote:
No, I have the error:
Error: function expected before (), not byte of type byte
Error: function expected before (), not ubyte of type ubyte
Error: function expected before (), not short of type short
Error: function expected
On Friday, 6 September 2013 at 17:15:03 UTC, H. S. Teoh wrote:
Hmm, could this be a possible (though somewhat ugly) workaround?
foreach (T; IntegralTypeList)
{
assert(factorial(to!T(3) == 6));
}
AFAIK, if T==int, then std.conv.to should simply alias
On Fri, Sep 06, 2013 at 10:05:47AM -0700, H. S. Teoh wrote:
On Fri, Sep 06, 2013 at 05:14:48PM +0200, ilya-stromberg wrote:
On Friday, 6 September 2013 at 14:26:17 UTC, H. S. Teoh wrote:
I thought the usual D idiom was to write factorial(5) and
factorial(BigInt(5)) and let the compiler
On Fri, Sep 06, 2013 at 05:14:48PM +0200, ilya-stromberg wrote:
On Friday, 6 September 2013 at 14:26:17 UTC, H. S. Teoh wrote:
I thought the usual D idiom was to write factorial(5) and
factorial(BigInt(5)) and let the compiler figure out which template
instance you wanted?
Yes, but it isn't
On Friday, 6 September 2013 at 15:47:27 UTC, Dicebot wrote:
On Friday, 6 September 2013 at 15:14:50 UTC, ilya-stromberg
wrote:
As monarch_dodra pointed above, we haven't got uniform
construction support.
Yeah, this one, contrary, seems to be really crucial feature
lacking.
Yes, I agree. It
06-Sep-2013 21:05, H. S. Teoh пишет:
On Fri, Sep 06, 2013 at 05:14:48PM +0200, ilya-stromberg wrote:
On Friday, 6 September 2013 at 14:26:17 UTC, H. S. Teoh wrote:
I thought the usual D idiom was to write factorial(5) and
factorial(BigInt(5)) and let the compiler figure out which template
On Friday, 6 September 2013 at 17:49:04 UTC, Jonathan M Davis
wrote:
Personally, I think that this is opening a whole can of worms
that should
never be opened. alias this already causes enough trouble for
stuff like
templates (primarily because it becomes far too easy to pass a
template
On Friday, 6 September 2013 at 13:01:14 UTC, Dicebot wrote:
On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut
wrote:
Its only a source of troubles in C++ because it is the default
behavior. But if you design a library it can make the usage of
your api easier and also you have a few
On Friday, September 06, 2013 12:33:05 ilya-stromberg wrote:
Do you have any plans to 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 =
On Fri, Sep 06, 2013 at 07:25:21PM +0200, ilya-stromberg wrote:
On Friday, 6 September 2013 at 17:15:03 UTC, H. S. Teoh wrote:
Hmm, could this be a possible (though somewhat ugly) workaround?
foreach (T; IntegralTypeList)
{
assert(factorial(to!T(3) == 6));
}
40 matches
Mail list logo
