On Apr 24, 2013, at 8:21 PM, Vladimir Panteleev vladi...@thecybershadow.net
wrote:
On Friday, 1 March 2013 at 11:12:02 UTC, Andrei Alexandrescu wrote:
(details to follow)
So, are there any details? Like, e.g. is there a dress code? :)
I believe you're expected to wear clothes.
On Tuesday, 16 April 2013 at 21:50:10 UTC, Sönke Ludwig wrote:
Changes:
- Support for a new buildRequirements field to be able to
specify
things like Don't treat warnings as errors or Allow use of
deprecated features
- A lot of improvements to the VisualD project generator
- Some
Am 26.04.2013 21:37, schrieb alex:
I want to inform you that Mono-D v0.5.2.4 can open Dub projects natively
now - no need for creating .dproj files explicitly anymore, just opening
package.json is required in order to have the project there.
It also handles include paths in the most common
On Friday, 26 April 2013 at 20:16:15 UTC, Sönke Ludwig wrote:
Am 26.04.2013 21:37, schrieb alex:
I want to inform you that Mono-D v0.5.2.4 can open Dub
projects natively
now - no need for creating .dproj files explicitly anymore,
just opening
package.json is required in order to have the
I'd say opening all dependencies is distracting. But being able to open
them quickly is really useful.
On Fri, Apr 26, 2013 at 10:26 PM, alex i...@alexanderbothe.com wrote:
On Friday, 26 April 2013 at 20:16:15 UTC, Sönke Ludwig wrote:
Am 26.04.2013 21:37, schrieb alex:
I want to inform you
On Friday, 26 April 2013 at 20:47:42 UTC, Rory McGuire wrote:
I'd say opening all dependencies is distracting. But being able
to open
them quickly is really useful.
I think I should create greyed-out references in the
pseudo-solution which can be enabled and loaded afterwards if
wanted. Or
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.
bool is a type with two values: false and true with the following conversion
rules:
false - 0
true - 1
0 value - false
non-zero
On Friday, 26 April 2013 at 05:02:50 UTC, Walter Bright wrote:
On 4/25/2013 7:54 PM, Kapps wrote:
This is just silly.
Changing enum defaultVal = 1 to defaultVal = 2 should never
result in calling a
different overload.
This does:
import core.stdc.stdio;
enum x =
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?
Yes.
On Friday, 26 April 2013 at 04:15:24 UTC, Manu wrote:
Why bother with 'auto'? Why not just make this default
behaviour?
That is the kind of question that we can answer when safety
problem are solved. This is why I would love to see both problem
separated : they are different.
Still need to
On 2013-04-25 19:57, Vladimir Panteleev wrote:
Regardless, the above (accessing objects in destructors) is not related
to the InvalidMemoryOperationError. See the documentation for it:
http://dlang.org/phobos/core_exception.html#.InvalidMemoryOperationError
Yeah, I though that was weird.
--
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 cast?
Yes.
+1
What about the implicit conversion for the
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
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
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
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
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
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
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
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
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 also
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
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,
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
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
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
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
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 that
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=1381876seqNum=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 =
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 of
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
On Friday, 26 April 2013 at 15:34:01 UTC, eles wrote:
Proposals:
Object.factory(.Human); // idem as Object.factory(module
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?
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 believe
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
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(module
name.Human);
Can't this one be done with a trivial change to the library,
for strings known at compile
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
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()?
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
literal and
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
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 to it - e.g.
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 about
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'
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
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
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
On 4/26/13, Andrej Mitrovic andrej.mitrov...@gmail.com 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
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 be
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
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
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 doesn't
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 andrej.mitrov...@gmail.com 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
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
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, for
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
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 andrej.mitrov...@gmail.com wrote:
An even better example:
import std.stdio;
void foo(bool x) { writeln(1); }
void foo(long x) { writeln(2); }
void main()
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
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 takes
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
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 think
On 27 April 2013 05:31, Jonathan M Davis jmdavisp...@gmx.com 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 param) {...}
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
as possible
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 andrej.mitrov...@gmail.com wrote:
An even better example:
import std.stdio;
void foo(bool x) { writeln(1); }
void foo(long x) { writeln(2); }
void main()
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
On 27 April 2013 12:26, Jonathan M Davis jmdavisp...@gmx.com 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
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 luismarq...@gmail.com
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
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
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
Hey all,
Can someone please explain to me how and why it is that
toStringz() and toUTFz() can be used in the following way?
string a = 123;
auto b = a.toStringz;
auto c = a.toUTFz;
Also, how is it that they can even be called as if they were
class methods? That is:
string a = 123;
auto b
1 - 100 of 165 matches
Mail list logo
