[Issue 8651] Slice op Slice throws exceptions (not errors), and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=8651 --- Comment #4 from monarchdo...@gmail.com 2012-09-25 23:26:30 PDT --- (In reply to comment #3) And someday even [1,2].dup will be nothrow. Doesn't dup allocate? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8726] New: About immutable and const constructors
http://d.puremagic.com/issues/show_bug.cgi?id=8726
Summary: About immutable and const constructors
Product: D
Version: D2
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: freeslav...@gmail.com
--- Comment #0 from Roman freeslav...@gmail.com 2012-09-25 23:31:52 PDT ---
Hello to all. Actually I posted this issue on D forums, but I was advised to
ask there. I want to discuss immutable and const constructors.
For a start let's write the simple class with two constructors:
class A
{
int x;
this() immutable
{
x = 42;
}
this()
{
x = 13;
}
}
void main()
{
//
}
Well, dmd passes this code, but what if we want to create some
object of class A?
void main()
{
A a = new A;
}
hello.d|177|Error: constructor hello.A.this called with argument
types:|
hello.d|177|Error: cannot implicitly convert expression (new A)
of type immutable(A) to hello.A|
Class A has mutable constructor, but for some reason immutable
one is called and then immutable object can not be converted to
type A, which is mutable.
Let's rewrite this line to this:
immutable A a = new A;
hello.d|173|Error: constructor hello.A.this called with argument
types:|
So what's the problem? Yes, both A's constructors really have
empty argument lists, but... ah. Let's try another way:
immutable A a = new immutable A;
hello.d|173|Error: found 'A' when expecting '('|
hello.d|173|Error: basic type expected, not ;|
hello.d|173|Error: found ';' when expecting ')'|
hello.d|174|Error: semicolon expected, not '}'|
Again not. Looks like it's not correct statement at all. So I
conclude there is no way to keep simultaneously both mutable and
immutable constructors with same argument list. But as we saw
above, compiler passes code if we don't create objects of class
A, although such permission has no sense.
Well, now let's rewrite our class using const specifier instead
of immutable
class A
{
int x;
this() const
{
x = 42;
}
this()
{
x = 13;
}
}
void main()
{
const A a = new A;
assert(a.x == 42);
}
Project is built without errors or warning, but we get assertion
failure in runtime. Error seems obvious: new A is constructed
like mutable and only then assigned to object of class const A.
Maybe the following code will be correct?
const A a = new const A;
hello.d|173|Error: found 'A' when expecting '('|
hello.d|173|Error: basic type expected, not ;|
hello.d|173|Error: found ';' when expecting ')'|
hello.d|174|Error: semicolon expected, not 'assert'|
But we get same errors as with immutable specifier.
I think, there is some compiler defect or problem of language design.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1115] incorrect flow analysis for scope(failure)
http://d.puremagic.com/issues/show_bug.cgi?id=1115 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #1 from Don clugd...@yahoo.com.au 2012-09-26 00:47:03 PDT --- Fixed hundreds of years ago. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8255] [CTFE] ICE when passing 'ref' literal
http://d.puremagic.com/issues/show_bug.cgi?id=8255 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Depends on||7988 --- Comment #2 from Don clugd...@yahoo.com.au 2012-09-26 00:45:55 PDT --- Before CTFE begins, the code in comment 1 is translated into: F().f((G __tmpsl5 = G(); , __tmpsl5)) The problem is that the comma expression is evaluated outside of CTFE. This would be fixed by bug 7988. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1328] Default class template parameters don't work as expected
http://d.puremagic.com/issues/show_bug.cgi?id=1328 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #3 from Don clugd...@yahoo.com.au 2012-09-26 00:51:01 PDT --- *** This issue has been marked as a duplicate of issue 1012 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1536] Literal '0' is improperly used to deduce an implicit template parameter
http://d.puremagic.com/issues/show_bug.cgi?id=1536
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #3 from Don clugd...@yahoo.com.au 2012-09-26 01:04:53 PDT ---
This example is unnecessarily complicated.
void CurryAll(A)(A x, A y)
{ }
void foo()
{
uint u = 0;
CurryAll(u, 0);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1390] Implicit Instantiation: delegate args from variadic template argument
http://d.puremagic.com/issues/show_bug.cgi?id=1390
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Version|1.020 |D1 D2
Summary|Implicit Instantiation: |Implicit Instantiation:
|delegate args from 2|delegate args from variadic
|template params |template argument
--- Comment #1 from Don clugd...@yahoo.com.au 2012-09-26 01:23:56 PDT ---
Reduced test case.
--
void bug1390a(A,U)(void delegate(U,A) dg, A arg)
{}
void bug1390(A,U...)(void delegate(U,A) dg, A arg)
{}
struct FooStruct {
void foo(uint i,char c) {}
}
void bar1390() {
auto temp = new FooStruct;
bug1390a!(char,uint)(temp.foo, 'c');
bug1390a(temp.foo, 'c');
bug1390!(char,uint)(temp.foo, 'c');
bug1390(temp.foo, 'c');
}
The '1390a' cases work, but on D1, the second '1390' fails. On D2 *both* of the
'1390' instantiations fail.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2456] cannot put catch statement inside finally block, missing line number
http://d.puremagic.com/issues/show_bug.cgi?id=2456 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||diagnostic CC||clugd...@yahoo.com.au Version|1.030 |D1 D2 Summary|cannot put catch statement |cannot put catch statement |inside finally block |inside finally block, ||missing line number --- Comment #3 from Don clugd...@yahoo.com.au 2012-09-26 01:30:46 PDT --- Applies also to D2.060. Has no line number in the error message in D1 or D2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8725] segmentation fault with negative-lookahead in module-level regex
http://d.puremagic.com/issues/show_bug.cgi?id=8725
Dmitry Olshansky dmitry.o...@gmail.com changed:
What|Removed |Added
CC||dmitry.o...@gmail.com
--- Comment #2 from Dmitry Olshansky dmitry.o...@gmail.com 2012-09-26
06:46:49 PDT ---
I suspect that is a long standing bug with compile-time evaluation that
compiler parses regex pattern at compile time wrongly (unlike at R-T).
See also: http://d.puremagic.com/issues/show_bug.cgi?id=7810
The problem is that once D compiler sees an initialized global variable it has
to const-fold it:
int fact10 = factorial(10);
//will compute and hardcode the value of factorial(10)
then with regex ...:
auto italic = regex( ... );
// *parses* and *generates* binary object for compiled regex pattern object
with all the datastructures for matching it
All of this *at compile time* via CTFE, see about it here (near the bottom of):
http://dlang.org/function.html
Though previously it only caused unexpectedly long compilation time (CTFE is
slow) and in a select cases it failed with assert *during compilation*, it
never segfaulted.
Probably internal structure has subtle corruption that self-test failed to
catch.
E.g this one also works because italic regex is created at run-time:
import std.stdio;
import std.regex;
void main() {
auto italic = regex( r\*
(?!\s+)
(.*?)
(?!\s+)
\*, gx );
string input = this * is* interesting, *very* interesting;
writeln( replace( input, italic, i$1/i ) );
}
Also a tip: the second lookahead should be lookbehind! As is is it will test
that \* is not a space indeed... Also both can be just \s, because \s+ matches
whenever \s matches. And since you don't capture the contents of
lookahead/lookbehind it'll be faster/simpler to use a single \s.
About SafeD: it shouldn't segfault but the program listed is @system (as this
is the default) :). Otherwise since regex is @trusted, it's my responsibilty to
verfiy that it is memory safe, so blame me (or rather the compiler).
To be actually in SafeD try putting @safe: at the top of your code or just tag
main and all functions with @safe.
AFAIK writeln in SafeD wouldn't work as it's still @system (obviously it
should be safe/trusted). To be honest SafeD hasn't been addressed properly in
the standard library yet.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8727] New: __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727
Summary: __traits(is_reserved_word, ) ?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-09-26 07:16:33 PDT ---
Maybe it's worth adding a new trait that tells what currently are reserved
words of D:
assert(__traits(is_reserved_word, import));
For an use case see:
http://d.puremagic.com/issues/show_bug.cgi?id=6946
It replaces a function like this, that risks becoming out of date:
bool isReservedWord(in string w) {
string[] reservedWords = abstract alias align asm
assert auto body bool break byte case cast catch cdouble cent cfloat
char class const continue creal dchar debug default delegate delete
deprecated do double else enum export extern false final finally
float for foreach foreach_reverse function goto idouble if ifloat
immutable import in inout int interface invariant ireal is lazy long
macro mixin module new nothrow null out override package pragma
private protected public pure real ref return scope shared short
static struct super switch synchronized template this throw true try
typedef typeid typeof ubyte ucent uint ulong union unittest ushort
version void volatile wchar while with __FILE__ __LINE__ __gshared
__thread __traits.split();
return canFind(reservedWords, w);
}
Such __traits is useful to exclude the reserved words from usages in code
generation, to avoid bugs or avoid mysterious error messages.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6946] Compile-time flags generator
http://d.puremagic.com/issues/show_bug.cgi?id=6946 --- Comment #6 from bearophile_h...@eml.cc 2012-09-26 07:28:19 PDT --- See also Issue 8727 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Keywords||pull CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-09-26 17:03:16 CEST --- https://github.com/D-Programming-Language/dmd/pull/1144 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 --- Comment #2 from bearophile_h...@eml.cc 2012-09-26 08:30:14 PDT --- (In reply to comment #1) https://github.com/D-Programming-Language/dmd/pull/1144 Thank you, only 45 minutes to see implemented one enhancement request of mine :-) (Regarding the comments inside your patch, foreach_reverse is quite useful. retro() will be acceptable only if the compiler recognizes it as special and guarantees to implement it with the the same efficiency of foreach_reverse in all cases. I think this will not happen, so I'll try to keep foreach_reverse inside the language.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #3 from monarchdo...@gmail.com 2012-09-26 08:52:13 PDT ---
(In reply to comment #2)
(In reply to comment #1)
https://github.com/D-Programming-Language/dmd/pull/1144
Thank you, only 45 minutes to see implemented one enhancement request of mine
:-)
(Regarding the comments inside your patch, foreach_reverse is quite useful.
retro() will be acceptable only if the compiler recognizes it as special and
guarantees to implement it with the the same efficiency of foreach_reverse in
all cases. I think this will not happen, so I'll try to keep foreach_reverse
inside the language.)
I don't want to hijack this pull request into off topic discussion, but is
foreach_reverse *really* scheduled for deprecation? Or is this just an ongoing
suggestion. If it is an ER, do you have a link to it?
IMO, The problem with retro is that it does not support natural slice syntax:
import std.range;
import std.stdio;
void main()
{
foreach_reverse(i; 0..10)
writeln(i, ...);
writeln(Fire!);
foreach(i; retro(0..10)) //NOPE
writeln(i, ...);
writeln(Fire!);
}
The equivalent code would require inserting an iota. Either from 9 to -1 (ew),
or from 0 to 10, then reversed (blargh):
void main()
{
foreach_reverse(i; 0..10)
writeln(i, ...);
writeln(Fire!);
foreach(i; iota(9, -1, -1)) //Ew
writeln(i, ...);
writeln(Fire!);
foreach(i; iota(0, 10).retro() ) //Blargh
writeln(i, ...);
writeln(Fire!);
}
Looking only at the syntax, I'd like to keep foreach_reverse thankyou very
much. I also doubt that the performance is anywhere near the same level.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8728] New: Allow optional message for @disable
http://d.puremagic.com/issues/show_bug.cgi?id=8728 Summary: Allow optional message for @disable Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-09-26 09:34:32 PDT --- @deprecated will soon have an optional message Issue 5481 https://github.com/D-Programming-Language/dmd/pull/463 I think we could use this for @disable too. E.g. when a user upgrades a library and some code ends up calling a method which is now disabled it would be nice if there was an error message stating why the method has become disabled. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8725] segmentation fault with negative-lookahead in module-level regex
http://d.puremagic.com/issues/show_bug.cgi?id=8725 --- Comment #3 from Val Markovic v...@markovic.io 2012-09-26 09:39:30 PDT --- Thanks for the explanation! WRT the regex string being faulty, I was aware of that; I was just experimenting when I encountered a segfault. Thanks for the pointer about adding @safe: at the top; too bad writeln is still @system. That kinda kills the usefulness of SafeD, doesn't it? I mean if I literally can't write a Hello World program in SafeD, then SafeD is quite far from ready. :) I've read the TDPL last week and this is my first encounter with writing real D code; all in all, the language is freaking awesome (goodbye C++) and I'm even willing to live with esoteric bugs in the compiler/libs if I can work around them. I understand that D is still a work-in-progress language. I intend to write a substantial (multi KLOC) D program as a learning experience; will report any bugs I find as I find them. Anyway, good luck fixing this. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-26 10:15:44 PDT --- I don't want to hijack this pull request into off topic discussion, but is foreach_reverse *really* scheduled for deprecation? I haven't gotten a clear answer on that. I don't think that there's much question that if we were completely redoing things, it wouldn't be in the language, and there's a definite contingent who want it gone. But I don't know whether Walter intends to axe it or not. AFAIK, no definitive decision was made on it. It's not on the list of features to be deprecated on dlang.org: http://dlang.org/deprecate.html There's probably a good chance that foreach_reverse will cease to work with delegates at some point even if it's kept, because it does exactly the same thing as foreach for delegates, making it a source of bugs. But there's probably a good chance that foreach_reverse is here to stay simply to avoid breaking code even if it's certain that we don't want it. Regardless, if you want someone like Walter who would know for sure what foreach_reverse's current fate is supposed to be, you'll probably have to post in the newsgroup (and short of Walter or Andrei saying something, I don't know if you can know for certain what the current situation is, since it's Walter's decision, and I'm not aware of him making a public decision on it). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8729] New: parse!bool does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=8729
Summary: parse!bool does not work correctly
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-26 10:29:46
PDT ---
This code
import std.conv;
import std.stdio;
void main()
{
auto str = 123 456.7 false;
auto i = parse!int(str);
auto d = parse!double(str);
auto b = parse!bool(str);
assert(i == 123);
assert(d == 456.7);
assert(b == false);
}
results in this exception when you run it
std.conv.ConvException@std/conv.d(2654): Can't parse string: bool should be
case-insensive 'true' or 'false'
./q(bool std.conv.parse!(bool, immutable(char)[]).parse(ref
immutable(char)[])+0x183) [0x43867b]
./q(_Dmain+0x42) [0x430ec2]
./q(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x1c) [0x43b240]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x3b) [0x43b287]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(main+0xd1) [0x43ab45]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7fd238fc1725]
If you change it to
import std.conv;
import std.stdio;
void main()
{
auto str = false 123 456.7;
auto b = parse!bool(str);
auto i = parse!int(str);
auto d = parse!double(str);
assert(i == 123);
assert(d == 456.7);
assert(b == false);
}
you get
std.conv.ConvException@std/conv.d(1771): Unexpected ' ' when converting from
type string to type int
./q(int std.conv.parse!(int, immutable(char)[]).parse(ref
immutable(char)[])+0x1b8) [0x431984]
./q(_Dmain+0x33) [0x430eb3]
./q(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x1c) [0x43b240]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x3b) [0x43b287]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(main+0xd1) [0x43ab45]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7f1286cc0725]
Just parsing out bool when it's first and then parsing _nothing_ else works,
but it seems like parsing it under any other circumstances fails (from what I
can tell anyway).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7810] [CTFE] Typesafe variadic function with array of structs
http://d.puremagic.com/issues/show_bug.cgi?id=7810
Dmitry Olshansky dmitry.o...@gmail.com changed:
What|Removed |Added
Summary|ctRegex!`a|b` asserts at|[CTFE] Typesafe variadic
|regex.d:1150|function with array of
||structs
--- Comment #6 from Dmitry Olshansky dmitry.o...@gmail.com 2012-09-26
11:47:45 PDT ---
I've finally pinned down this bugger.
The problem is in typesafe variadic function if the parameter type is a struct.
See simple test below:
//encoded IR instruction
struct Bytecode
{
uint raw;
}
int fn1(T)(T[] items...)
{
assert(items[0] == 20);
return 42;
}
int fn2(T)(T[] items...)
{
assert(items[0] == Bytecode(20));
return 42;
}
//this passes...
static assert(fn1(20, 30) == 42);
//this dies inside of fn2
static assert(fn2(Bytecode(20), Bytecode(30)) == 42);
void main()
{//both of these pass at R-T
assert(fn1(20, 30) == 42);
assert(fn2(Bytecode(20), Bytecode(30)) == 42);
}
Output:
sr_micro.d(15): Error: assert(items[0u] == Bytecode(20u)) failed
sr_micro.d(23):called from here: fn2((Bytecode[2u] __arrayArg6 = void;
, __arrayArg6[0u] = Bytecode(20u) , __arrayArg6[1u] = Bytecode(30u) ,
cast(Bytecode[])__arrayArg6))
sr_micro.d(23):while evaluating: static assert(fn2((Bytecode[2u]
__arrayArg6 = void;
, __arrayArg6[0u] = Bytecode(20u) , __arrayArg6[1u] = Bytecode(30u) ,
cast(Bytecode[])__arrayArg6)) == 42)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8730] New: writeln stops on a nul character, even if passed a D string
http://d.puremagic.com/issues/show_bug.cgi?id=8730
Summary: writeln stops on a nul character, even if passed a D
string
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: destructiona...@gmail.com
--- Comment #0 from Adam D. Ruppe destructiona...@gmail.com 2012-09-26
13:12:00 PDT ---
import std.stdio;
void main() {
writeln(test\0gone);
}
only prints test. writefln(%s) prints the whole thing.
$ ./test | xxd
000: 7465 7374 0a
as you can see the data is indeed not being printed; it isn't just invisible on
my screen.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8729] parse!bool does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=8729
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2012-09-26 13:48:08 PDT ---
(In reply to comment #0)
This code
import std.conv;
import std.stdio;
void main()
{
auto str = 123 456.7 false;
auto i = parse!int(str);
auto d = parse!double(str);
auto b = parse!bool(str);
assert(i == 123);
assert(d == 456.7);
assert(b == false);
}
results in this exception when you run it
std.conv.ConvException@std/conv.d(2654): Can't parse string: bool should be
case-insensive 'true' or 'false'
./q(bool std.conv.parse!(bool, immutable(char)[]).parse(ref
immutable(char)[])+0x183) [0x43867b]
./q(_Dmain+0x42) [0x430ec2]
./q(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x1c) [0x43b240]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x3b) [0x43b287]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(main+0xd1) [0x43ab45]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7fd238fc1725]
If you change it to
import std.conv;
import std.stdio;
void main()
{
auto str = false 123 456.7;
auto b = parse!bool(str);
auto i = parse!int(str);
auto d = parse!double(str);
assert(i == 123);
assert(d == 456.7);
assert(b == false);
}
you get
std.conv.ConvException@std/conv.d(1771): Unexpected ' ' when converting from
type string to type int
./q(int std.conv.parse!(int, immutable(char)[]).parse(ref
immutable(char)[])+0x1b8) [0x431984]
./q(_Dmain+0x33) [0x430eb3]
./q(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x1c) [0x43b240]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x3b) [0x43b287]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(main+0xd1) [0x43ab45]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7f1286cc0725]
Just parsing out bool when it's first and then parsing _nothing_ else works,
but it seems like parsing it under any other circumstances fails (from what I
can tell anyway).
Sounds like the implementation is looking for a literal true or false, and
is forgetting to skip leading ws.
This works:
import std.conv;
import std.stdio;
void main()
{
auto str = 123 456.7 false;
auto i = parse!int(str);
auto d = parse!double(str);
str = str[1..$]; //manually skip ws.
auto b = parse!bool(str);
assert(i == 123);
assert(d == 456.7);
assert(b == false);
}
I can look into it for next week, unless somebody else solves it by then.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8729] parse!bool does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=8729
--- Comment #2 from monarchdo...@gmail.com 2012-09-26 13:52:15 PDT ---
(In reply to comment #1)
(In reply to comment #0)
This code
import std.conv;
import std.stdio;
void main()
{
auto str = 123 456.7 false;
auto i = parse!int(str);
auto d = parse!double(str);
auto b = parse!bool(str);
assert(i == 123);
assert(d == 456.7);
assert(b == false);
}
results in this exception when you run it
std.conv.ConvException@std/conv.d(2654): Can't parse string: bool should be
case-insensive 'true' or 'false'
./q(bool std.conv.parse!(bool, immutable(char)[]).parse(ref
immutable(char)[])+0x183) [0x43867b]
./q(_Dmain+0x42) [0x430ec2]
./q(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x1c)
[0x43b240]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x3b)
[0x43b287]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(main+0xd1) [0x43ab45]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7fd238fc1725]
If you change it to
import std.conv;
import std.stdio;
void main()
{
auto str = false 123 456.7;
auto b = parse!bool(str);
auto i = parse!int(str);
auto d = parse!double(str);
assert(i == 123);
assert(d == 456.7);
assert(b == false);
}
you get
std.conv.ConvException@std/conv.d(1771): Unexpected ' ' when converting from
type string to type int
./q(int std.conv.parse!(int, immutable(char)[]).parse(ref
immutable(char)[])+0x1b8) [0x431984]
./q(_Dmain+0x33) [0x430eb3]
./q(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x1c)
[0x43b240]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x3b)
[0x43b287]
./q(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x2a) [0x43abba]
./q(main+0xd1) [0x43ab45]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7f1286cc0725]
Just parsing out bool when it's first and then parsing _nothing_ else works,
but it seems like parsing it under any other circumstances fails (from what
I
can tell anyway).
Sounds like the implementation is looking for a literal true or false, and
is forgetting to skip leading ws.
[SNIP]
Bigtime!
// string to bool conversions
Target parse(Target, Source)(ref Source s)
if (isSomeString!Source !is(Source == enum)
is(Unqual!Target == bool))
{
if (s.length = 4 icmp(s[0 .. 4], true)==0)
{
s = s[4 .. $];
return true;
}
if (s.length = 5 icmp(s[0 .. 5], false)==0)
{
s = s[5 .. $];
return false;
}
parseError(bool should be case-insensive 'true' or 'false');
assert(0);
}
I got this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8729] parse!bool does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=8729
--- Comment #3 from monarchdo...@gmail.com 2012-09-26 14:36:53 PDT ---
FYI, parse!int also has the same problem. Only floating point types seem to
behave correctly:
import std.conv;
import std.stdio;
void main()
{
auto str = 456.7 123;
auto d = parse!double(str);
auto i = parse!int(str);
assert(d == 456.7);
assert(i == 123);
}
On the split side, to! seems to parse things it should actually be rejecting:
import std.conv;
import std.stdio;
void main()
{
auto str = 456.7 123;
auto d = to!double( 456.7); //Passes, but shouldn't
auto i = to!int( 123); //Correctly throws
}
Just logging here the bugs I find, still on this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
