[Issue 3715] std.string.format can't use const/immutable toString functions
http://d.puremagic.com/issues/show_bug.cgi?id=3715
--- Comment #4 from Steven Schveighoffer 2010-09-20
04:36:35 PDT ---
Well, first of all, toString should always be const.
But pure and nothrow are two options that are also valid. I think some real
thought needs to go into delegates and function pointers, and what can
implicitly cast. Right now, there are no implicit casts between function
pointers (except const casts which are invalid anyways).
As a workaround, you can do something like this:
struct A {
/*pure nothrow?*/ string toString() const { return "A"; }
string toString() {const(A)*me = &this; return me.toString();}
}
What this does is put a common implementation for each overload so you don't
have to rewrite it.
When the requirements change (and they will, because toString should be const),
then in most cases you can just get away with a const function. If you want to
have pure and nothrow available, then you still have to do something like this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3420] Allow string import of files using subdirectories
http://d.puremagic.com/issues/show_bug.cgi?id=3420 Don changed: What|Removed |Added Summary|[PATCH] Allow string import |Allow string import of |of files using |files using subdirectories |subdirectories | Severity|regression |enhancement --- Comment #19 from Don 2010-09-20 04:45:03 PDT --- This link: https://www.securecoding.cert.org/confluence/display/seccode/FIO02-C.+Canonicalize+path+names+originating+from+untrusted+sources states that: "Producing canonical file names for Windows operating systems is extremely complex and beyond the scope of this standard. The best advice is to try to avoid making decisions based on a path, directory, or file name [Howard 2002]. Alternatively, use operating-system-based mechanisms, such as access control lists (ACLs) or other authorization techniques." Thus, this issue might not be fixable on Windows. I'm downgrading this all the way from 'regression' to 'enhancement', since it was a security bug that it ever worked at all. Perhaps the bug should just be closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4382] Same syntax to access items of Proxy and Tuple and more
http://d.puremagic.com/issues/show_bug.cgi?id=4382 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] Ddoc generats invalid output for documentation comments with non paired paranthasis
http://d.puremagic.com/issues/show_bug.cgi?id=3554
--- Comment #8 from bearophile_h...@eml.cc 2010-09-20 05:03:38 PDT ---
This bug doesn't seem fixed in dmd 2.049. This program:
/// Return a random number in [0, 10 $(LPAREN)
void foo() {}
void main() {}
Generates an html that doesn't show the closing left parenthesis:
...
Return a random number in [0, 10
...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4900] New: compiler still slow due to a single function
http://d.puremagic.com/issues/show_bug.cgi?id=4900 Summary: compiler still slow due to a single function Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: schvei...@yahoo.com --- Comment #0 from Steven Schveighoffer 2010-09-20 05:20:20 PDT --- As shown in bug 4721, there is still a problem in the compiler when compiling projects with a large number of symbols. Here is a profiled version of dmd 2.048 compiling unit tests for dcollections: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 80.31 11.9911.9919000 0.63 0.63 searchfixlist 0.67 12.09 0.10 203173 0.00 0.00 StringTable::search(char const*, unsigned int) 0.60 12.18 0.09 369389 0.00 0.00 Lexer::scan(Token*) 0.54 12.26 0.08 953613 0.00 0.00 ScopeDsymbol::search(Loc, Identifier*, int) 0.47 12.33 0.07 1449798 0.00 0.00 calccodsize ... Note the searchfixlist function uses 80% of the runtime (the compiler takes 17 seconds to produce a result), but only has 19000 calls. Compare that to other functions which have orders of magnitude more calls but nothing takes more than 0.7%. An examination of the searchfixlist function shows that it is a search through a linked list. I'm unsure if the same methodology (replace with hash) can be applied as was in issue 4721, but it would be good to investigate possible ideas to replace the algorithm there. I opened this as a separate bug, because the original bug in 4721 was fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 Steven Schveighoffer changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Steven Schveighoffer 2010-09-20 05:21:19 PDT --- Closing this, opened the new issue as bug 4900. Fixed in 2.049 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4290] 'Fragile' opCmp/toHash signature errors
http://d.puremagic.com/issues/show_bug.cgi?id=4290
--- Comment #5 from bearophile_h...@eml.cc 2010-09-20 05:25:27 PDT ---
> Why should the D compiler refuse to compile them?
The D compiler has to disallow or warn against common traps.
> This is probably a job for a lint-type tool.
If some bug may be found at compile-time and it's not too much hard to find it
(example: it doesn't require flow analysis), then in my opinion it's a job of
the (D) compiler to avoid the bug. Clang compiler designers seem to agree with
me.
> This has nothing to do with memory safety, which is what safe D is all about.
I was not talking about memory safety or SafeD, I was talking about code safety
in general. Generally D needs to be designed to avoid common bugs, when
possible (another example of bug that I'd like D to avoid is to accept strings
like "<<>" as operators for the operator overloading string template).
> For example, you can mis-define some range by doing something
> like popfront(). The compiler won't refuse to compile this, and shouldn't.
> But it will refuse to allow it to be passed into a range-accepting function.
> Where do we draw the line?
That's a nice example. I don't have a generic answer for your question, but to
let this function be accepted and silently ignored:
int opCmp(ref const Foo f) {
because this is the only correct one:
int opCmp(ref const Foo f) const {
is too much bug-prone, in my opinion. This is beyond the line for me.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4901] New: std.algorithm.sort does not compile for interfaces that cannot be printed.
http://d.puremagic.com/issues/show_bug.cgi?id=4901
Summary: std.algorithm.sort does not compile for interfaces
that cannot be printed.
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer 2010-09-20
05:44:56 PDT ---
An assert meant to check the sort algorithm inadvertently makes it uncompilable
for interfaces.
reduced test case:
import std.algorithm;
interface I
{
@property int x();
}
bool iless(I i1, I i2)
{
return i1.x < i2.x;
}
void main()
{
I[] x;
std.algorithm.sort!iless(x);
}
outputs:
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/conv.d(95): Error:
template std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T)
&& isInputRange!(S) && isSomeChar!(ElementType!(S))) does not match any
function template declaration
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/conv.d(95): Error:
template std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T)
&& isInputRange!(S) && isSomeChar!(ElementType!(S))) cannot deduce template
function from argument types !(string)(I)
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/conv.d(95): Error:
template instance errors instantiating template
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/conv.d(202): Error:
template instance std.conv.to!(string).to!(I) error instantiating
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/conv.d(95):
instantiated from here: toImpl!(string,I[])
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/conv.d(3556):
instantiated from here: to!(I[])
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/conv.d(3572):
instantiated from here: textImpl!(string,string,string,I[])
/home/steves/dmd-2.049/linux/bin/../../src/phobos/std/algorithm.d(5187):
instantiated from here: text!(string,string,I[])
testsort.d(16):instantiated from here:
sort!(iless,cast(SwapStrategy)0,I[])
Line 5187 of std.algorithm is this:
assert(isSorted!lessFun(r), text(Range.stringof, ": ", r));
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4290] 'Fragile' opCmp/toHash signature errors
http://d.puremagic.com/issues/show_bug.cgi?id=4290 --- Comment #6 from Steven Schveighoffer 2010-09-20 06:03:43 PDT --- (In reply to comment #5) > > Why should the D compiler refuse to compile them? > > The D compiler has to disallow or warn against common traps. But opCmp is a valid function! I can still call it, even though it's not put into the typeinfo. > > This is probably a job for a lint-type tool. > > If some bug may be found at compile-time and it's not too much hard to find it > (example: it doesn't require flow analysis), then in my opinion it's a job of > the (D) compiler to avoid the bug. Clang compiler designers seem to agree with > me. But it's not a bug! opCmp is a valid symbol name for a function, and can be called with the arguments you specify. In fact, it even works with the comparison operators. There is nothing inherently special about opCmp. We need to add special notation conveying our intentions to the compiler (that it should be used in the TypeInfo). It's like refusing to compile a function because it's not an english word. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] Ddoc generats invalid output for documentation comments with non paired paranthasis
http://d.puremagic.com/issues/show_bug.cgi?id=3554 --- Comment #9 from Johannes Pfau 2010-09-20 07:28:22 PDT --- Yeah, I also brought this up on the dmd-internals mailing list recently. The problem is that the patch replaces the parenthesis with LPAREN and RPAREN macros. Dmd should define these by default but it doesn't. Not defined ddoc macros expand to an empty string. A workaround is to define these macros in an ddoc file passed to dmd or in the macro section of a source file; the definitions should look like this: RPAREN = ) LPAREN = ( -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4899] Ddoc's warnings about stray parens should include file and line numbers
http://d.puremagic.com/issues/show_bug.cgi?id=4899
Johannes Pfau changed:
What|Removed |Added
CC||johannesp...@gmail.com
--- Comment #1 from Johannes Pfau 2010-09-20 07:43:56
PDT ---
Printing line numbers is implemented and should work. It works with the test
case in 3554.
test.d(6): Warning: Ddoc: Stray '('. This may cause incorrect Ddoc output. Use
$(LPAREN) instead for unpaired left parentheses.
test.d(16): Warning: Ddoc: Stray ')'. This may cause incorrect Ddoc output. Use
$(RPAREN) instead for unpaired right parentheses.
Could you provide a test case where the line numbers aren't printed?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4892] Regression(1.062, D1 only) Stack overflow when compiling a recursive alias declaration
http://d.puremagic.com/issues/show_bug.cgi?id=4892 Don changed: What|Removed |Added Keywords||ice-on-invalid-code CC||clugd...@yahoo.com.au Summary|Infinite loop when |Regression(1.062, D1 only) |compiling a recursive alias |Stack overflow when |declaration |compiling a recursive alias ||declaration Severity|normal |regression --- Comment #1 from Don 2010-09-20 08:10:25 PDT --- Regression since 1.062; D1 only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4871] compiler crash: dmd: mtype.c:875: void Type::check(): Assertion `tn->mod & 4 || tn->mod & 1' failed.
http://d.puremagic.com/issues/show_bug.cgi?id=4871 Don changed: What|Removed |Added Keywords||ice-on-valid-code CC||clugd...@yahoo.com.au --- Comment #1 from Don 2010-09-20 08:13:35 PDT --- (In reply to comment #0) > I'm new to D so this might be invalid syntax but it shouldn't crash the > compiler. Yes. Thanks for the excellent reduced test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4712] Issue of destructor for temporary instance of structs
http://d.puremagic.com/issues/show_bug.cgi?id=4712 Don changed: What|Removed |Added Keywords||wrong-code Severity|normal |critical -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4714] Cannot return ref this when struct has invariant
http://d.puremagic.com/issues/show_bug.cgi?id=4714 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au Severity|normal |critical --- Comment #1 from Don 2010-09-20 08:33:37 PDT --- This looks very similar to bug 3273 (struct invariant + dtor fails to compile (no line number)). But my patch for 3273 doesn't fix this one. Suggests that my patch to 3273 is probably wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3273] Regression(2.031): struct invariant + dtor fails to compile (no line number)
http://d.puremagic.com/issues/show_bug.cgi?id=3273 --- Comment #6 from Don 2010-09-20 08:34:31 PDT --- Have just discovered bug 4714, which still fails with this patch. I think this patch is wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4632] Copy constructor not invoked on array reallocation
http://d.puremagic.com/issues/show_bug.cgi?id=4632 Don changed: What|Removed |Added Keywords||wrong-code CC||clugd...@yahoo.com.au Severity|normal |major -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4641] Associative arrays of structs with alias this broken.
http://d.puremagic.com/issues/show_bug.cgi?id=4641 Don changed: What|Removed |Added Keywords||wrong-code CC||clugd...@yahoo.com.au Severity|major |critical --- Comment #1 from Don 2010-09-20 08:37:54 PDT --- Related to bug 2451 and possibly also 2943. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4613] temporary generated inside foreach is not correctly destructed
http://d.puremagic.com/issues/show_bug.cgi?id=4613 Don changed: What|Removed |Added Keywords||wrong-code CC||clugd...@yahoo.com.au Severity|major |critical --- Comment #2 from Don 2010-09-20 08:41:23 PDT --- Probably a dup of bug 3516 -- the worst open bug in DMD. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4696] function pointers to std.math functions cause linking errors
http://d.puremagic.com/issues/show_bug.cgi?id=4696 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #1 from Don 2010-09-20 08:44:31 PDT --- *** This issue has been marked as a duplicate of issue 4541 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4541] Intrinsic functions do not have pointers
http://d.puremagic.com/issues/show_bug.cgi?id=4541 Don changed: What|Removed |Added CC||necrom...@gmail.com --- Comment #1 from Don 2010-09-20 08:44:31 PDT --- *** Issue 4696 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4524] Bus error with nested struct
http://d.puremagic.com/issues/show_bug.cgi?id=4524 Don changed: What|Removed |Added Keywords||wrong-code CC||clugd...@yahoo.com.au Severity|normal |critical -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 Don changed: What|Removed |Added Keywords||wrong-code CC||clugd...@yahoo.com.au Severity|major |critical -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4470] Problems with std.bigint mod and divide
http://d.puremagic.com/issues/show_bug.cgi?id=4470 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3516] Destructor not called on temporaries
http://d.puremagic.com/issues/show_bug.cgi?id=3516 a...@aligature.com changed: What|Removed |Added CC||a...@aligature.com --- Comment #8 from a...@aligature.com 2010-09-20 08:51:34 PDT --- This bug also seems like it could be the cause of http://d.puremagic.com/issues/show_bug.cgi?id=4613 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] Ddoc generats invalid output for documentation comments with non paired paranthasis
http://d.puremagic.com/issues/show_bug.cgi?id=3554 --- Comment #10 from bearophile_h...@eml.cc 2010-09-20 12:45:52 PDT --- I may open a different bug report that asks for LPAREN and RPAREN macros to be defined in dmd, to be sure this problem doesn't get lost. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] Ddoc generats invalid output for documentation comments with non paired paranthasis
http://d.puremagic.com/issues/show_bug.cgi?id=3554 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #11 from Jonathan M Davis 2010-09-20 16:28:48 PDT --- They _are_ defined. They're $(LPAREN) and $(RPAREN). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] Ddoc generats invalid output for documentation comments with non paired paranthasis
http://d.puremagic.com/issues/show_bug.cgi?id=3554 --- Comment #12 from bearophile_h...@eml.cc 2010-09-20 16:35:12 PDT --- (In reply to comment #11) > They _are_ defined. They're $(LPAREN) and $(RPAREN). Then where is the bug? Because there is a problem still. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] Ddoc generats invalid output for documentation comments with non paired paranthasis
http://d.puremagic.com/issues/show_bug.cgi?id=3554 --- Comment #13 from Jonathan M Davis 2010-09-20 16:45:48 PDT --- Sorry, I didn't read the bug report all the way through. A new warning relating to unmatched parens in ddoc popped up with 2.049, and it specifically mentions $(LPAREN) and $(RPAREN), indicating that they are defined (hence why I told you that they are). But if they aren't working, then that would indicate that they're supposed to be defined but aren't, and then a bug report should indeed be filed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4290] 'Fragile' opCmp/toHash signature errors
http://d.puremagic.com/issues/show_bug.cgi?id=4290
--- Comment #7 from bearophile_h...@eml.cc 2010-09-20 16:46:25 PDT ---
It seems we are in irreducible disagreement here.
> But opCmp is a valid function! I can still call it, even though it's not put
into the typeinfo.
Of course. But when it is well formed it is also a *special* function, because
the compiler uses it automatically in some useful situations.
> But it's not a bug!
If you define a Foo struct like this, it' quite probably a bug in your code:
struct Foo {
int x;
const bool opEquals(ref const Foo f) {
return true;
}
int opCmp(ref const Foo f) {
return 0;
}
hash_t toHash() {
return 10;
}
}
> There is nothing inherently special about opCmp.
It's special because there is a contract between the compiler and the
programmer, that such functions are used for example when you sort an array of
structs or you put them in an associative array. If the compiler in some
situations silently doesn't use such functions when the programmer surely
intended them to be used that way by the compiler, then there's something wrong
with the compiler.
> We need to add special notation conveying our intentions to the compiler
This is wrong. D language is designed to adopt the safe behaviour (= less bug
prone, I am not talking about safeD) on default. So if feel the need of it,
then you may add special notation to say the compiler to not use a function
named opCmp for comparisons.
> It's like refusing to compile a function because it's not an english word.
This is not the same thing. In Foo there are functions that have exactly the
same name as the standard methods, and their signature too is very similar. I
am not asking for the compiler to give a warning for a opcompare or even opcmp
function.
And by the way, what I am asking is an extension of what dmd is already doing,
because in many other cases if you try to compile a struct that defined a wrong
opCmp or toHash the compiler do shows an error. So I am asking for the error
messages to cover this case too.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3847] To avoid a C code bug
http://d.puremagic.com/issues/show_bug.cgi?id=3847
--- Comment #11 from bearophile_h...@eml.cc 2010-09-20 17:24:18 PDT ---
(In reply to comment #10)
> It sums up the typical attitude I've seen towards them.
Some C++ programmers don't even know about 'and' and 'or' because the C++
compilers do nothing to suggest, encourage or force the usage of those more
readable and less bug-prone operators. The D compiler can avoid that trouble if
somehow && || become a legacy or deprecated (but probably supported still)
feature.
It's also a matter of idioms and customs: D is a new language, it's not just an
extension of the C language. So new D users usually accept the need to learn
new customs and new idioms specific of the D language. D does many things
differently from D (and even when it accepts C syntax, it's quite discouraged,
like using "int a[];"). If D style guides, standard library, newsgroups, and
books use 'and' and 'or' operators, new D programmers will use them.
Thanks to bug 4077, a problem is now mitigated, if the original program with
the thirdElementIsThree() function is compiled with dmd 2.049 plus warnings,
the compiler shows:
test.d(4): a.length >= 3 must be parenthesized when next to operator &
test.d(4): a[2] == 3 must be parenthesized when next to operator &
But fixing bug 4077 doesn't help bugs like:
void main() {
bool a, b;
if (a & b) {}
}
The usage of 'and' and 'or' operators avoids this class of bugs too.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4407] Catch wrong argument<->attribute assignments in methods
http://d.puremagic.com/issues/show_bug.cgi?id=4407
--- Comment #1 from bearophile_h...@eml.cc 2010-09-20 17:32:46 PDT ---
To keep the language semantics more uniform (instead of special-casing just in
methods), all redundant assignments may be flagged as errors:
void main() {
int x;
x = x; // error, redundant assignment
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #4 from bearophile_h...@eml.cc 2010-09-20 17:41:37 PDT --- It seems that not just GCC flags this a possible error, in the Java audit rules in some Google Software this problem is named "Dangling Else": http://code.google.com/intl/en-EN/webtoolkit/tools/codepro/doc/features/audit/audit_rules_com.instantiations.assist.eclipse.auditGroup.possibleErrors.html#com.instantiations.assist.eclipse.audit.danglingElse It says: This audit rule finds places in the code where else clauses are not preceded by a block because these can lead to dangling else errors. Example if (a > 0) if (a > 100) b = a - 100; else b = -a; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4407] Catch wrong argument<->attribute assignments in methods
http://d.puremagic.com/issues/show_bug.cgi?id=4407 --- Comment #2 from bearophile_h...@eml.cc 2010-09-20 17:47:19 PDT --- It's present among the Semantic Errors of Java code in the Google Web Toolkit too: http://code.google.com/intl/en-EN/webtoolkit/tools/codepro/doc/features/audit/audit_rules_com.instantiations.assist.eclipse.auditGroup.semanticErrors.html#com.instantiations.assist.eclipse.audit.redundantAssignment -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4902] No label and variable with the same name error
http://d.puremagic.com/issues/show_bug.cgi?id=4902 --- Comment #1 from bearophile_h...@eml.cc 2010-09-20 18:01:57 PDT --- So far in my code I have never had a bug caused by this, so I consider this low-priority. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4902] New: No label and variable with the same name error
http://d.puremagic.com/issues/show_bug.cgi?id=4902
Summary: No label and variable with the same name error
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-09-20 18:00:10 PDT ---
This compiles with no errors, but maybe it's better to refuse (and show an
error) when a label has the same name of a variable:
enum int FOO = 1;
int main() {
goto FOO;
FOO: return FOO;
}
That helps keep code tidy, and also helps to avoid probably wrong code like
(note the missing 'case'):
enum int CONST1 = 1;
enum int CONST2 = 2;
void main() {
int x = 1;
switch (x) {
case CONST1:
break;
CONST2:
break;
default:
break;
}
}
Something similar toi the second situation is present among the Semantic Errors
of Java code in the Google Web Toolkit too:
http://code.google.com/intl/en-EN/webtoolkit/tools/codepro/doc/features/audit/audit_rules_com.instantiations.assist.eclipse.auditGroup.possibleErrors.html#com.instantiations.assist.eclipse.audit.nonCaseLabelInSwitch
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3847] To avoid a C code bug
http://d.puremagic.com/issues/show_bug.cgi?id=3847
--- Comment #12 from Stewart Gordon 2010-09-20 18:04:33 PDT ---
(In reply to comment #11)
> Some C++ programmers don't even know about 'and' and 'or' because
> the C++ compilers do nothing to suggest, encourage or force the
> usage of those more readable and less bug-prone operators. The D
> compiler can avoid that trouble if somehow && || become a legacy or
> deprecated (but probably supported still) feature.
But because && and || are by far the most commonly used forms, and
probably most modern languages with C-derived syntax are designed on
this very basis, deprecating them would probably confuse the
programmer by making D the odd one out.
Moreover, a trend that has distinguished C and its derivatives from
Pascal, Fortran, SQL et al is the tendency to make use of symbols,
thereby keeping down the number of keywords in the language. D has
continued this trend by doing away with the little-used and and or.
OK, so D has is and in, but these aren't things for which other
C-like languages have symbols (at least, I'm not sure if JS/PHP ===
is similar enough to count).
> If D style guides, standard library, newsgroups, and books use
> 'and' and 'or' operators, new D programmers will use them.
And maybe get confused when they find that they don't behave in the
same way as in Perl and PHP. Probably the obscurity of C's and/or
has meant that the designers of Perl and PHP saw nothing wrong with
changing the precedence. (Though why PHP's designer saw fit to
change the associativity of ?: is a mystery I haven't solved.)
> But fixing bug 4077 doesn't help bugs like:
>
> void main() {
> bool a, b;
> if (a & b) {}
> }
How's that a bug? When a and b are bools, they behave the same!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #5 from Jonathan M Davis 2010-09-20 18:26:31 PDT --- "The dangling else problem" is essentially the official name of the problem of knowing which if to put the last else with if you have a series of if statements with an else statement at the end and no braces to indicate where it should go. The canonical way to solve it is to put the else with the last if. It's a classic problem in programming language grammars. Of course, the problem here is that the spacing that the programmer used seems to indicate that he did not intend the else to go with the last if, but the grammar is quite unambiguous on the matter. Still, it is likely an error on the programmer's part. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3847] To avoid a C code bug
http://d.puremagic.com/issues/show_bug.cgi?id=3847 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from bearophile_h...@eml.cc 2010-09-20 18:30:52 PDT --- (In reply to comment #12) Stewart Gordon: > But because && and || are by far the most commonly used forms, and > probably most modern languages with C-derived syntax are designed on > this very basis, deprecating them would probably confuse the > programmer by making D the odd one out. I understand this. On the other hand Python and Delphi use 'or' and 'and' (Python is partially derived from C). I know some Python programmers interested in D. > D has continued this trend by doing away with the little-used and and or. And D uses a semicolon where Java uses 'implements' and 'extends'. > OK, so D has is and in, but these aren't things for which other > C-like languages have symbols In Python 'is' and 'in' have similar semantics. > And maybe get confused when they find that they don't behave in the > same way as in Perl and PHP. Probably this is a confusion for D newbies only, while what I have suggested is meant to help life of normal D programmers. > How's that a bug? When a and b are bools, they behave the same! OK. I close this enhancement request. If I will find other bug-prone situations I will reopen it. Thank you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3847] To avoid a C code bug
http://d.puremagic.com/issues/show_bug.cgi?id=3847 Brad Roberts changed: What|Removed |Added Resolution|FIXED |WONTFIX --- Comment #14 from Brad Roberts 2010-09-20 18:37:57 PDT --- It's not 'fixed'. It's either 'invalid' or 'wontfix' or 'notabug'. I'd prefer the latter, but since it's not available, going with 'wontfix'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4903] New: opopAssignRight is needed for operator overloading
http://d.puremagic.com/issues/show_bug.cgi?id=4903 Summary: opopAssignRight is needed for operator overloading Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don 2010-09-20 19:02:14 PDT --- Cases where it is required are limited, but one example is BigInt. int x = 14; BigInt y = 3; x = x / y; // OK. x /= y; // No way to support this Applies to /= and %=. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4742] int % BigInt should work
http://d.puremagic.com/issues/show_bug.cgi?id=4742 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #2 from Don 2010-09-20 19:02:41 PDT --- http://www.dsource.org/projects/phobos/changeset/2042 Fixes / and %. int /= BigInt and int %= BigInt can't be done with the new operator overloading -- there's no such thing as opopAssignRight(). I have created bug 4903 for that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4290] 'Fragile' opCmp/toHash signature errors
http://d.puremagic.com/issues/show_bug.cgi?id=4290 --- Comment #8 from Kevin Bealer 2010-09-20 20:04:28 PDT --- I think when you are defining opCmp, it's a bit like overriding a function signature, therefore, if D tries to prevent function hijacking, it makes perfect sense for it to do the same thing here. I have no problem with an enforced single interface for opCmp and opEquals and so on. I have no problem with having flexible interfaces where const or ref is optional and up to the user. I think either of these will work -- and I prefer the second, actually. Flexible is good, so long as it is practical to implement. But for the compiler to correctly generate code that calls the flexible API (pick any signature you like) for opCmp when "<" is used, but does not call it at all when ".sort" is used unless the signature matches a hidden template? Come on, it can't really be meant to work like that, right? It doesn't make sense for the language to have two different behaviors. It's an inconsistency that doesn't make any sense from a language or user point of view. I do think that for value types the .sort and T[] behaviors are best done in something like a template mechanism, semantically. Classes can use the Object.opCmp version but for struct and primitives it makes sense to fully and automatically specialize the code and build that into the language. (Or at least call whichever opCmp is present.) Kevin -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4898] Can't see parent function's variables from nested functions when debugging
http://d.puremagic.com/issues/show_bug.cgi?id=4898 Aldo Nunez changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Aldo Nunez 2010-09-20 21:03:48 PDT --- I guess it would be an enhancement. I updated the bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4446] Templated function result can't be ref if tiargs are infered w/ value tiarg
http://d.puremagic.com/issues/show_bug.cgi?id=4446 Shin Fujishiro changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Shin Fujishiro 2010-09-20 22:03:05 PDT --- *** This issue has been marked as a duplicate of issue 3175 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3175] rejects templated ref return function
http://d.puremagic.com/issues/show_bug.cgi?id=3175 Shin Fujishiro changed: What|Removed |Added CC||rsi...@gmail.com --- Comment #2 from Shin Fujishiro 2010-09-20 22:03:05 PDT --- *** Issue 4446 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3847] To avoid a C code bug
http://d.puremagic.com/issues/show_bug.cgi?id=3847 --- Comment #15 from BCS 2010-09-20 22:15:25 PDT --- (In reply to comment #11) > more > readable and less bug-prone operators. Franky I find the fact that && and || are not keywords make them *More* readable and as a result *Less* bug-prone. But there's no accounting for taste, yours or mine. One point to you, 1 point to me and Walter has trump. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4899] Ddoc's warnings about stray parens should include file and line numbers
http://d.puremagic.com/issues/show_bug.cgi?id=4899
--- Comment #2 from Jonathan M Davis 2010-09-20 23:47:02
PDT ---
/++
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
+/
module d;
void main()
{
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
