On 07/03/2014 05:16 AM, Wanderer wrote:
On Wednesday, 2 July 2014 at 17:21:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
By not putting these functions on Object, it allows them to have whatever
attributes they need when declared in derived types. Without that,
we're stuck
That's not the p
On Wednesday, 2 July 2014 at 17:21:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
By not putting these functions on Object, it allows them to
have whatever
attributes they need when declared in derived types. Without
that, we're stuck
That's not the problem of the Object class, that's the p
On Wed, 02 Jul 2014 11:33:54 +
Wanderer via Digitalmars-d wrote:
> "~" operator has to do with toString(), because it performs
> string concatenation (at least documentation says so) and
> toString() is the common way to convert arbitrary object into a
> string.
The common way to convert any
On Wednesday, 2 July 2014 at 11:33:56 UTC, Wanderer wrote:
On Wednesday, 2 July 2014 at 09:24:39 UTC, Jonathan M Davis via
Digitalmars-d wrote:
"Languages like Java and C# are forced to, because they do not
have proper templates and thus have to use Object directly in
many cases."
That's not
On Wednesday, 2 July 2014 at 11:33:56 UTC, Wanderer wrote:
On Wednesday, 2 July 2014 at 09:24:39 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The ~ operator has nothing to do with toString. Strings are
arrays, and ~
works with arrays already. ~ doesn't work with Object and will
only work with
On Wednesday, 2 July 2014 at 09:24:39 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The ~ operator has nothing to do with toString. Strings are
arrays, and ~
works with arrays already. ~ doesn't work with Object and will
only work with
user-defined types which define opBinary!"~". The only thin
On Wed, 02 Jul 2014 07:07:17 +
Wanderer via Digitalmars-d wrote:
> On Tuesday, 1 July 2014 at 01:13:25 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > The long term plan is to remove toString, opEquals, toHash, and
> > opCmp from
> > Object so that the derived classes can decide whether
On Wednesday, 2 July 2014 at 07:07:18 UTC, Wanderer wrote:
On Tuesday, 1 July 2014 at 01:13:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The long term plan is to remove toString, opEquals, toHash,
and opCmp from
Object so that the derived classes can decide whether to make
them const or
no
On Tuesday, 1 July 2014 at 01:13:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The long term plan is to remove toString, opEquals, toHash, and
opCmp from
Object so that the derived classes can decide whether to make
them const or
not. Unlike Java and C#, we have proper templates, so we can
On Monday, June 30, 2014 22:22:50 francesco cattoglio via Digitalmars-d wrote:
> I found out today that the following code won't compile:
>
> import std.conv;
>
> class MyClass {}
>
> void doStuffKo(const MyClass instance)
> {
> string temp = to!(string)(instance);
> }
>
> Everything compiles fin
I found out today that the following code won't compile:
import std.conv;
class MyClass {}
void doStuffKo(const MyClass instance)
{
string temp = to!(string)(instance);
}
Everything compiles fine if I remove the const from the function
signature.
I found out this issue named in ea
11 matches
Mail list logo
