On Friday, 26 April 2013 at 02:13:03 UTC, Ali Çehreli wrote:
On 04/25/2013 06:44 PM, Maxim Fomin wrote:
> On Thursday, 25 April 2013 at 21:05:43 UTC, Ali Çehreli wrote:
> Looks like value range propagation bug because 1 is integer
literal and
> should be converted to long. There is no way for 1
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
On 4/25/2013 10:49 PM, Ali Çehreli wrote:
It certainly behaves that way but it isn't an integer type and
that's why it is
unintuitive.
But it is an integer type.
Regarding bool type as integer type is C atavism and should be
a
On Friday, 26 April 2013 at 06:16:29 UTC, deadalnix wrote:
On Friday, 26 April 2013 at 05:02:50 UTC, Walter Bright wrote:
A bool is an integer with the range 0..1
This "feature" never has been useful to me.
+1
On 4/25/2013 11:42 PM, Manipulator wrote:
What about the implicit conversion for the other types? I could imagine that
they could cause similar bugs. Why not get rid of the implicit conversion?
Implicit conversions make the menagerie of integer types tractable. Explicit
casts are a sledgehamme
On Friday, 26 April 2013 at 06:42:28 UTC, Manipulator wrote:
On Friday, 26 April 2013 at 06:18:29 UTC, deadalnix wrote:
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
The real issue is do you want to have the implicit
conversions:
0 => false
1 => true
or would you require a c
On 4/25/2013 11:16 PM, deadalnix wrote:
This "feature" never has been useful to me.
It has been useful to me. So there!
It has caused bug.
The bug is not providing an overload for int.
Additionally, the behavior is inconsistent :
int i = 1;
foo(i); // Don't call the bool version.
It is
On 4/26/2013 12:07 AM, Maxim Fomin wrote:
Regarding bool type as integer type is C atavism and should be abandoned.
There's a very lng history of 0 being regarded as false and 1 as true - it
goes well beyond C.
This leads to comic sitatuation presented in the thread when changing litera
Are you really saying that 'sort!((a, b) => a > b)(array);' is
too verbose??
I consider 'sort!("a > b")(array);' to be **too terse**: there is
nothing here telling the reader what a and b are supposed to be.
BR,
renoX
On Friday, 26 April 2013 at 08:00:28 UTC, Walter Bright wrote:
On 4/26/2013 12:07 AM, Maxim Fomin wrote:
Regarding bool type as integer type is C atavism and should be
abandoned.
There's a very lng history of 0 being regarded as false and
1 as true - it goes well beyond C.
This should b
On 4/26/2013 1:14 AM, Maxim Fomin wrote:
I argue the correct solution is to call integer function with integer parameter
when integer value is passed.
I'm sorry, but that's an assertion not an argument.
The other issue with your assertion, as I explained to Ali, is that D does not
have a noti
On Friday, 26 April 2013 at 08:03:14 UTC, Walter Bright wrote:
On 4/25/2013 11:16 PM, deadalnix wrote:
This "feature" never has been useful to me.
It has been useful to me. So there!
It has caused bug.
The bug is not providing an overload for int.
Additionally, the behavior is inconsiste
On 04/26/2013 01:58 AM, Zach the Mystic wrote:
...
I also thought of the trick mentioned by Timon, where the compiler
infers the need or lack thereof for the value/reference type in
templates based on what things are done within the function body. But as
you said, figuring out the rules for maki
On Friday, 26 April 2013 at 08:13:48 UTC, renoX wrote:
I consider 'sort!("a > b")(array);' to be **too terse**: there
is nothing here telling the reader what a and b are supposed to
be.
Sure there is - it's called "convention". Since all the functions
in `std.algorithm` that accept delegates
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
On 4/25/2013 10:49 PM, Ali Çehreli wrote:
It certainly behaves that way but it isn't an integer type and
that's why it is
unintuitive.
But it is an integer type.
It is an integral type _internally_.
A bool type should have the v
On 04/26/2013 07:02 AM, Walter Bright wrote:
> A bool is an integer with the range 0..1
This is True for the type but for the actual code it looks different.
There 0 == false. and everything else is true.
import std.stdio;
void main() {
if(10) {
writefln("%d is also true", 10);
}
}
And indeed they do. I did face some very weird bugs caused by
that already.
What sort of bugs has it caused for you? Just interested, not
questioning whether or not it's a source of bugs.
On Friday, 26 April 2013 at 08:00:28 UTC, Walter Bright wrote:
On 4/26/2013 12:07 AM, Maxim Fomin wrote:
Regarding bool type as integer type is C atavism and should be
abandoned.
There's a very lng history of 0 being regarded as false and
1 as true - it goes well beyond C.
Assembly, P
24.04.2013 12:47, deadalnix пишет:
On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote:
19.04.2013 11:45, deadalnix пишет:
On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
Another try to describe the problem:
When I get a delegate, I'd like to use it unles
On Friday, 26 April 2013 at 12:34:55 UTC, ixid wrote:
And indeed they do. I did face some very weird bugs caused by
that already.
What sort of bugs has it caused for you? Just interested, not
questioning whether or not it's a source of bugs.
The last time I experienced that feature was with
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
Sorry, I was rude here and I apologize. Finally, D is (at least)
a wonderful place to discuss and test new ideas and,
On Friday, 26 April 2013 at 08:03:14 UTC, Walter Bright wrote:
On 4/25/2013 11:16 PM, deadalnix wrote:
This "feature" never has been useful to me.
It has been useful to me. So there!
If you want an int to behave like a bool, then by all means go
ahead and write the code yourself, I don't w
On Friday, 26 April 2013 at 08:00:28 UTC, Walter Bright wrote:
On 4/26/2013 12:07 AM, Maxim Fomin wrote:
Regarding bool type as integer type is C atavism and should be
abandoned.
There's a very lng history of 0 being regarded as false and
1 as true - it goes well beyond C.
That is tru
Should this be supported?
double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];
(it's not supported at the moment)
Just to clarify, this is supported, of course:
double[8] foo = void;
foo[0] = 1.0;
foo[1] = 2.0;
foo[3] = 3.0;
foo[4] = 3.5;
Luís Marques:
Should this be supported?
double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void,
void];
(it's not supported at the moment)
I think I have not needed this so far. It looks dangerous.
Generally D tries to initialize variables. What are your use
cases?
Bye,
bearophile
Hi bearophile.
This was just an academic question. It just seemed to me that if
"double[8] foo = void" was deemed to warrant support, that it is
a bit unorthogonal not to support the void in the specific
indexes. This is just nitpicking, but I thought it might be worth
asking, it could be tha
Creating a class instance from a string with Object.factory()
method requires the name of the module:
http://www.informit.com/articles/article.aspx?p=1381876&seqNum=6
module main;
Human person = cast(Human)Object.factory("main.Human");
However, if one rename the module (let's say into "newmain
On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
Alternatively, a function/variable could be provided inside the
module, returning the module name as a string, so that one could
write:
Object.factory(__MODULE__, ".Human");
On Friday, 26 April 2013 at 14:58:35 UTC, Luís Marques wrote:
Should this be supported?
double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void,
void];
(it's not supported at the moment)
which reminds me about the proposal to allow declaration of
static arrays with
double[$] foo = [1.0
On Fri, 26 Apr 2013 17:36:31 +0200, eles wrote:
> On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
>
> Alternatively, a function/variable could be provided inside the module,
> returning the module name as a string, so that one could write:
>
> Object.factory(__MODULE__, ".Human");
Instead
On Friday, 26 April 2013 at 15:45:27 UTC, eles wrote:
which reminds me about the proposal to allow declaration of
static arrays with
double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];
Seems nice.
double[4] foo = [1.0, 2.0];
is accepted, which is a bit strange (I think the compiler
On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
Proposals:
Object.factory(".Human"); // idem as Object.factory("name>.Human");
Can't this one be done with a trivial change to the library, for
strings known at compile time, by checking at compile time if the
string starts with a dot? Wou
BTW, I was working on a Object.factory scenario right now (!) and
stumbled on the limitation that the class can only have a default
constructor. Couldn't you call a non-default constructor by
passing var args to Object.factory()?
On Friday, 26 April 2013 at 15:36:32 UTC, eles wrote:
On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
Alternatively, a function/variable could be provided inside the
module, returning the module name as a string, so that one
could write:
Object.factory(__MODULE__, ".Human");
I believ
Further inspection suggests that the BetaClass object I was
accessing was already finalized by the time the AlphaClass object
got around to trying to mess with it. Conclusion is that whether
it's the in-destructor access or not, it's simply not safe to try
to clean things up this way. I think
On Friday, 26 April 2013 at 16:06:14 UTC, Luís Marques wrote:
On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
Proposals:
Object.factory(".Human"); // idem as Object.factory("name>.Human");
Can't this one be done with a trivial change to the library,
for strings known at compile time, by
On Friday, 26 April 2013 at 15:52:02 UTC, Justin Whear wrote:
On Fri, 26 Apr 2013 17:36:31 +0200, eles wrote:
On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
Alternatively, a function/variable could be provided inside
the module,
returning the module name as a string, so that one could
On Friday, 26 April 2013 at 16:13:44 UTC, Luís Marques wrote:
BTW, I was working on a Object.factory scenario right now (!)
and stumbled on the limitation that the class can only have a
default constructor. Couldn't you call a non-default
constructor by passing var args to Object.factory()?
T
On Friday, 26 April 2013 at 15:59:32 UTC, Luís Marques wrote:
On Friday, 26 April 2013 at 15:45:27 UTC, eles wrote:
which reminds me about the proposal to allow declaration of
static arrays with
double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];
Seems nice.
double[4] foo = [1.0,
On 04/26/2013 12:03 AM, Maxim Fomin wrote:
> On Friday, 26 April 2013 at 02:13:03 UTC, Ali Çehreli wrote:
>> On 04/25/2013 06:44 PM, Maxim Fomin wrote:
>>
>> > On Thursday, 25 April 2013 at 21:05:43 UTC, Ali Çehreli wrote:
>>
>> > Looks like value range propagation bug because 1 is integer
>> lite
On Friday, 26 April 2013 at 14:58:35 UTC, Luís Marques wrote:
Should this be supported?
double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void,
void];
(it's not supported at the moment)
Why would you ever want this? I can't even think of a
hypothetical use case.
On 4/26/2013 6:51 AM, deadalnix wrote:
The last time I experienced that feature was with a char getting casted to bool
implicitly and then appended to a string, causing super weird behavior after
when using the resulting (corrupted) string.
void main()
{
bool b = 'c';
}
dmd -c foo
foo.d(4
On 4/26/2013 5:01 AM, Robert Schadek wrote:
Anyway, I think no implicit casts would be wonderful, sure everybody
would hate it at first but than...
I've used a language with no implicit casts. It didn't get better, and I have an
enduring dislike of it.
On 4/26/2013 7:33 AM, deadalnix wrote:
On Friday, 26 April 2013 at 08:00:28 UTC, Walter Bright wrote:
On 4/26/2013 12:07 AM, Maxim Fomin wrote:
Regarding bool type as integer type is C atavism and should be abandoned.
There's a very lng history of 0 being regarded as false and 1 as true -
On Friday, April 26, 2013 14:15:07 Manu wrote:
> > I mean is that the way that auto ref should work with non-templated
> > functions
> > is that
> >
> > auto foo(auto ref T param) {...}
> >
> > becomes
> >
> > auto foo(ref T param) {...}
> >
> > underneath the hood. Then when you pass an rvalue
On Thursday, April 25, 2013 23:01:30 Walter Bright wrote:
> On 4/25/2013 10:49 PM, Ali Çehreli wrote:
> > It certainly behaves that way but it isn't an integer type and that's why
> > it is unintuitive.
>
> But it is an integer type.
That was one of C's big mistakes. There's nothing whatsoever ab
On 04/26/2013 09:11 PM, Walter Bright wrote:
On 4/26/2013 5:01 AM, Robert Schadek wrote:
Anyway, I think no implicit casts would be wonderful, sure everybody
would hate it at first but than...
I've used a language with no implicit casts. It didn't get better, and I
have an enduring dislike of
On Friday, 26 April 2013 at 10:33:17 UTC, Timon Gehr wrote:
On 04/26/2013 01:58 AM, Zach the Mystic wrote:
But as
you said, figuring out the rules for making the compiler smart
enough to
choose the right one seems like a hard task.
I think it is easy.
If it forwards to another
'auto ref' t
26-Apr-2013 03:20, Zach the Mystic пишет:
On Wednesday, 24 April 2013 at 19:33:51 UTC, Dmitry Olshansky wrote:
24-Apr-2013 20:08, qznc пишет:
What are you actually worried about? Compile times? Program size?
Startup time?
It affects all of it.
I don't know if you are right, but I think the
26-Apr-2013 07:23, Jonathan M Davis пишет:
On Wednesday, April 24, 2013 16:03:47 Dmitry Olshansky wrote:
What we need is to re-arrange the module hierarchy (and we need that
anyway) so that we split off the "concept" part of modules to a separate
package.
Thoughts? Other ideas?
I'm a bit di
On Saturday, 20 April 2013 at 08:31:34 UTC, Brian Schott wrote:
This uses ANTLR, as the other parser generators can't handle
D's grammar.
I'm beginning to think that ANTRL is not up to the task either.
I've somehow managed to get the grammar to the point where it
correctly parses several phob
On Friday, 26 April 2013 at 19:37:48 UTC, Jonathan M Davis wrote:
The main place where casting would be annoying - if conditions
and loop
conditions - already insert an explicit cast underneat the hood.
IMO it still makes no sense to have the implicit casting done in
conditional statements be
On 4/26/13, Andrej Mitrovic wrote:
> An even better example:
import std.stdio;
void foo(bool x) { writeln("1"); }
void foo(long x) { writeln("2"); }
void main()
{
foo(1); // "1"
foo(false ? 2 : 1); // "2"
}
Kill it with fire.
On 4/26/2013 1:16 PM, Timon Gehr wrote:
On 04/26/2013 09:11 PM, Walter Bright wrote:
On 4/26/2013 5:01 AM, Robert Schadek wrote:
Anyway, I think no implicit casts would be wonderful, sure everybody
would hate it at first but than...
I've used a language with no implicit casts. It didn't get b
Whatever the choices are of whether bool is a 1-bit integer or a
a logical true/false value, this should not happen:
enum e = 1;
void main()
{
foo(e); // bool
}
static e = 1;
void main()
{
foo(e); // long
}
The reason being that according to the language spec, the
constant "1" should b
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
The real issue is do you want to have the implicit conversions:
0 => false
1 => true
or would you require a cast?
The idea of a "true number" and a "false number" doesn't make
sense, so yes.
On 4/26/2013 12:37 PM, Jonathan M Davis wrote:
There's nothing whatsoever about bool that
makes sense as an integral type.
This is where our perspectives sharply diverge. A bool is a 1 bit integer type.
Take a look at this, for example:
http://d.puremagic.com/issues/show_bug.cgi?id=9963
Mat
On Friday, 26 April 2013 at 21:14:54 UTC, Walter Bright wrote:
A bool is a 1 bit integer type.
.sizeof returns bytes, not bits, and says that bool is of size 1.
You're just asking for bugs if you allow ref to accept rvalues.
We've had problems like this before when some literals were
treated as lvalues. The behavior of a function which takes its
argument by ref and the behavior of one which takes its
argument by auto ref are fundamentally different.
On Friday, 26 April 2013 at 21:14:54 UTC, Walter Bright wrote:
On 4/26/2013 12:37 PM, Jonathan M Davis wrote:
There's nothing whatsoever about bool that
makes sense as an integral type.
This is where our perspectives sharply diverge. A bool is a 1
bit integer type. Take a look at this, for ex
On Friday, 26 April 2013 at 21:01:17 UTC, Brian Schott wrote:
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
The real issue is do you want to have the implicit conversions:
0 => false
1 => true
or would you require a cast?
The idea of a "true number" and a "false number" does
On 4/26/2013 1:59 PM, Diggory wrote:
The actual value shouldn't be taken into
account when determining which overload to call, only the type should matter,
D has an interesting feature called VRP (value range propagation), where
implicit conversion very much depends on the value. For example:
On 4/26/2013 1:59 PM, Andrej Mitrovic wrote:
On 4/26/13, Andrej Mitrovic wrote:
An even better example:
import std.stdio;
void foo(bool x) { writeln("1"); }
void foo(long x) { writeln("2"); }
void main()
{
foo(1); // "1"
foo(false ? 2 : 1); // "2"
}
Kill it with fire.
How abo
On Friday, 26 April 2013 at 21:32:32 UTC, Tove wrote:
On Friday, 26 April 2013 at 21:01:17 UTC, Brian Schott wrote:
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
Sometimes due to bad coding standards I´m forced to write...
if((.long expression with not immediately apparent
Tove:
Sometimes due to bad coding standards I´m forced to write...
if((.long expression with not immediately apparent operator
precedence)!=0)
... absolutely appalling, kills readability with extra () etc.
I think here people are not asking to disallow that. A 0 and 1
can be false and t
On Friday, April 26, 2013 14:14:55 Walter Bright wrote:
> On 4/26/2013 12:37 PM, Jonathan M Davis wrote:
> > There's nothing whatsoever about bool that
> > makes sense as an integral type.
>
> This is where our perspectives sharply diverge. A bool is a 1 bit integer
> type. Take a look at this, fo
On Saturday, April 27, 2013 00:26:05 Dmitry Olshansky wrote:
> Thinking more of it - the idea would have been neat and elegant with a
> variation on DIP 15. Then std.xyz.trait would be the trait part of a
> package.
>
> http://wiki.dlang.org/DIP15
We really do need a variant of DIP 15 or 16. I ac
On Friday, 26 April 2013 at 21:37:14 UTC, Walter Bright wrote:
On 4/26/2013 1:59 PM, Andrej Mitrovic wrote:
On 4/26/13, Andrej Mitrovic wrote:
An even better example:
import std.stdio;
void foo(bool x) { writeln("1"); }
void foo(long x) { writeln("2"); }
void main()
{
foo(1); // "1"
On Friday, 26 April 2013 at 21:21:50 UTC, Diggory wrote:
You're just asking for bugs if you allow ref to accept
rvalues. We've had problems like this before when some
literals were treated as lvalues. The behavior of a function
which takes its argument by ref and the behavior of one which
take
On Friday, April 26, 2013 23:21:49 Diggory wrote:
> > You're just asking for bugs if you allow ref to accept rvalues.
> > We've had problems like this before when some literals were
> > treated as lvalues. The behavior of a function which takes its
> > argument by ref and the behavior of one which
On Friday, April 26, 2013 14:34:45 Walter Bright wrote:
> D has an interesting feature called VRP (value range propagation), where
> implicit conversion very much depends on the value.
VRP is a fantastic feature, but I think that it's coming back to bite us
somewhat if foo(1) calls an overload wh
On Friday, 26 April 2013 at 21:34:44 UTC, Walter Bright wrote:
void foo(short) { ... back up my files ... }
void foo(long) { ... launch nuclear missiles ... }
is a bad program.
The government of North Korea would probably be perfectly happy
with this program, but then again, that's a
On Fri, Apr 26, 2013 at 08:05:45PM -0400, Jonathan M Davis wrote:
> On Friday, April 26, 2013 14:34:45 Walter Bright wrote:
> > D has an interesting feature called VRP (value range propagation), where
> > implicit conversion very much depends on the value.
>
> VRP is a fantastic feature, but I thi
On 27 April 2013 05:31, Jonathan M Davis wrote:
> On Friday, April 26, 2013 14:15:07 Manu wrote:
> > > I mean is that the way that auto ref should work with non-templated
> > > functions
> > > is that
> > >
> > > auto foo(auto ref T param) {...}
> > >
> > > becomes
> > >
> > > auto foo(ref T para
On Friday, 26 April 2013 at 19:22:51 UTC, Walter Bright wrote:
I remember once a language that tried to define true and false
as something other than 1 and 0. It was horrible.
Don't need to look far away. Most shell do that.
On Friday, 26 April 2013 at 21:14:54 UTC, Walter Bright wrote:
On 4/26/2013 12:37 PM, Jonathan M Davis wrote:
There's nothing whatsoever about bool that
makes sense as an integral type.
This is where our perspectives sharply diverge. A bool is a 1
bit integer type.
Then why does it convert
On Friday, 26 April 2013 at 21:32:32 UTC, Tove wrote:
On Friday, 26 April 2013 at 21:01:17 UTC, Brian Schott wrote:
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
The real issue is do you want to have the implicit
conversions:
0 => false
1 => true
or would you require a cast?
On Saturday, April 27, 2013 10:21:32 Manu wrote:
> > > Why bother with 'auto'? Why not just make this default behaviour?
> >
> > For the same reason that T& doesn't take rvalues in C++ while const T&
> > does.
> > There's a big difference between wanting an argument to be passed as
> > efficiently
On Friday, 26 April 2013 at 21:37:14 UTC, Walter Bright wrote:
On 4/26/2013 1:59 PM, Andrej Mitrovic wrote:
On 4/26/13, Andrej Mitrovic wrote:
An even better example:
import std.stdio;
void foo(bool x) { writeln("1"); }
void foo(long x) { writeln("2"); }
void main()
{
foo(1); // "1"
On Saturday, 27 April 2013 at 01:43:12 UTC, deadalnix wrote:
On Friday, 26 April 2013 at 21:14:54 UTC, Walter Bright wrote:
On 4/26/2013 12:37 PM, Jonathan M Davis wrote:
There's nothing whatsoever about bool that
makes sense as an integral type.
This is where our perspectives sharply diverge
On 27 April 2013 12:26, Jonathan M Davis wrote:
> On Saturday, April 27, 2013 10:21:32 Manu wrote:
> > > > Why bother with 'auto'? Why not just make this default behaviour?
> > >
> > > For the same reason that T& doesn't take rvalues in C++ while const T&
> > > does.
> > > There's a big differenc
I don't see myself ever getting on board with this auto-ref
idea. I just
think it's crazy. It makes no sense to me, they are completely
unrelated
concepts. It will only lead to confusion.
I'm back at scope-ref. Kenji is right as far as I'm concerned.
Not to
mention, he actually did the work.
On Friday, 26 April 2013 at 21:34:44 UTC, Walter Bright wrote:
On 4/26/2013 1:59 PM, Diggory wrote:
The actual value shouldn't be taken into
account when determining which overload to call, only the type
should matter,
D has an interesting feature called VRP (value range
propagation), where
On Fri, 26 Apr 2013 07:58:34 -0700, Luís Marques
wrote:
Should this be supported?
double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];
(it's not supported at the moment)
Have you considered what this does? Consider a standard [1.0, 2.0] call:
In essence, it pushes 1.0 and
On Friday, 26 April 2013 at 17:58:04 UTC, John Colvin wrote:
Why would you ever want this? I can't even think of a
hypothetical use case.
The questions started as academic, motivated by the apparent lack
of orthogonality. As far as a practical scenario, right now this
is the best I can come u
On Saturday, 27 April 2013 at 01:37:22 UTC, deadalnix wrote:
On Friday, 26 April 2013 at 19:22:51 UTC, Walter Bright wrote:
I remember once a language that tried to define true and false
as something other than 1 and 0. It was horrible.
Don't need to look far away. Most shell do that.
D can
Is this what some of you are asking for?
bool a = true; // ok
bool b = false;// ok
bool c = 1; // error, no implicit conversion
bool c = getInt();// error? ok?
int x = 42;
if(x) { ... } // ok (doesn't this imply c =
getInt() ok to
On Thu, 25 Apr 2013 23:01:30 -0700, Walter Bright
wrote:
D tries very hard to avoid the notion of a "better" match. It goes with
an exact match, followed by one with implicit conversions. All implicit
conversions are considered equally good. Ambiguity is resolved by
invoking "partial ord
On Saturday, 27 April 2013 at 05:54:48 UTC, Luís Marques wrote:
Is this what some of you are asking for?
bool a = true; // ok
Yes
bool b = false;// ok
Yes
bool c = 1; // error, no implicit conversion
Yes
bool c = getInt();// error? ok?
Ye
On Thu, 25 Apr 2013 10:57:13 -0700, Vladimir Panteleev
wrote:
On Thursday, 25 April 2013 at 16:17:57 UTC, Jacob Carlborg wrote:
You cannot access GC controlled memory in class destructors.
Not true.
Can you be more specific? Maybe the wording was too strong. Should say
"you shouldn't
On 27 April 2013 13:29, Diggory wrote:
> I don't see myself ever getting on board with this auto-ref idea. I just
>> think it's crazy. It makes no sense to me, they are completely unrelated
>> concepts. It will only lead to confusion.
>>
>> I'm back at scope-ref. Kenji is right as far as I'm conc
91 matches
Mail list logo
