[Issue 2588] std.signals should not use 'length' stealth keyword in indexing
http://d.puremagic.com/issues/show_bug.cgi?id=2588 Denis verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||verylonglogin@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8023] (Regression git) Methods defined in external object files when template alias parameter is involved
http://d.puremagic.com/issues/show_bug.cgi?id=8023 --- Comment #3 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-05-04 01:38:44 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d420faebda45eb27596697594a61ecd2a6d3b3d7 Fix issue 8016 Regression Methods defined in external object files when template alias parameter is involved Make the fix for bug 2962 a bit less aggressive. Still passes all test cases for 2962. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8016] Methods defined in external object files when template alias parameter is involved
http://d.puremagic.com/issues/show_bug.cgi?id=8016 Leandro Lucarella leandro.lucare...@sociomantic.com changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #10 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-05-04 02:00:44 PDT --- (In reply to comment #9) The test cases were reverted because they failed in the auto-tester. This is because that patch only partially fix this issue, it seems that there are 2 issues in this test case and only one is being fix in the patch. The patch completely fixes bug 8023 though. So please re-apply pull #922 (now pull #923: https://github.com/D-Programming-Language/dmd/pull/923). Wait for the autotester to run to make sure is passing now that the fix for 8023 is merged. I'm sorry I made such a mess of this bug report, but it was quite tricky because I kept discovering bugs exposed by it. I will close this bug as INVALID and open a new one with a proper description of the issue that is left after the patch. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8030] New: Multiple override are allowed using mixin template
http://d.puremagic.com/issues/show_bug.cgi?id=8030
Summary: Multiple override are allowed using mixin template
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis verylonglogin@gmail.com 2012-05-04 13:33:36 MSD
---
IMHO this should rise a compiler error:
---
mixin template T() {
override string f() { return T; }
}
class A {
string f() { return A; }
}
class B: A {
mixin T;
override string f() { return B; }
mixin T;
}
void main() {
A b = new B;
assert(b.f() == B); // This passes
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8031] New: If a class have some signals it's impossible for a derived class to have any signals
http://d.puremagic.com/issues/show_bug.cgi?id=8031
Summary: If a class have some signals it's impossible for a
derived class to have any signals
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis verylonglogin@gmail.com 2012-05-04 14:55:44 MSD
---
`Signal` methods should never ever by virtual. We don't want user to override
connect/disconnect etc.
All `Signal` methods are virtual. As a result with current named mixin
templates behavior (they can add virtual methods):
---
import std.signals;
class A {
mixin Signal created;
}
class B : A {
mixin Signal moved; // Yes, it overrides `created` signal!
}
---
or even worse:
---
import std.signals;
class A {
mixin Signal s1;
mixin Signal s2;
}
class B : A {
mixin Signal s3; // Guess what A signal is overriden?
}
---
or even worse:
---
import std.signals;
class A {
mixin Signal s1;
}
class B : A {
// Guess what exectly is overriden?
// Spoiler: unhook is overriden!
mixin Signal!int s2;
}
---
Hello heisenbugs for every unlucky person who doesn't compile with `-w`!
That's why it's impossible to use `std.signals` in any GUI library for now.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #27 from Andrei Alexandrescu and...@metalanguage.com 2012-05-04 04:03:36 PDT --- (In reply to comment #26) No it isn't. OOP doesn't say anything about contracts. The concept of contract is different and the question here is how both interact in a specific corner case. Walter's explanation creates confusion because he uses the wrong vocabulary (i.e. OOP instead of Design by Contract). I realize I am not very good at explaining this. I seriously recommend reading Meyer's book Object Oriented Programming. It's only $5.99. Is that book handle the corner case we are talking about here ? Yes. There's another book on the subject called Design by Contract, by Example. I wouldn't recommend it as a good book in general but it does teach the topic. If it does, I'd be interested in what is the reasoning. Well it's not all that reasonable to expect someone to essentially copy the text from the book or summarize it for you. The fact is that all document I read at this point do not say anything about this. It means you are reading the wrong documents. It takes literally under a minute to find relevant documents all over. As evidence for (1), is there any OOP language that does it these other ways? Spec# does not, as Andrei researched and pointed out. For (2), you've got a high bar to overcome, and certainly have an opportunity for a groundbreaking academic paper. I read many paper on the subject. None was covering the corner case we are talking about here. Without this corner case, both solutions satisfy requirements. However, the chosen one is simpler (in contract can simply be added to the function body). There's no reason to doubt you are telling the truth, so this must be quite an interesting case of confirmation bias as you seem to have read only what doesn't infirm your hypothesis and glossed over everything that does. As an example, google for design by contract inheritance The literally FIRST hit takes to a slide deck, see http://goo.gl/544fU. There there is theory and examples on how contracts work. I'd be happy to see ONE argument on favor of the current behavior. Everybody is doing it isn't a valid argument. It's a very valid argument. DbC is established. People learn about DbC from various places and they come to apply it in D. They'd be surprised and annoyed that D doesn't do what it's supposed to do. There are of course other arguments, which you can find in the literature. This is not the time and place for a course in DbC. We are D, we know everybody is using C++ and PHP (among others), and we do also know that such languages are horribly crippled by all sort of crazyness. Everybody is doing it isn't an argument. On the other hand many are also doing some good things so gratuitously not doing them doesn't help, either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3526] Mixin of member function not overriden by enclosing scope
http://d.puremagic.com/issues/show_bug.cgi?id=3526 Denis verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||verylonglogin@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8030] Multiple override are allowed using mixin template
http://d.puremagic.com/issues/show_bug.cgi?id=8030
--- Comment #1 from Denis verylonglogin@gmail.com 2012-05-04 15:48:06 MSD
---
Or, if this shouldn't rise an error, this also should compiles:
---
class B: A {
mixin T;
mixin T;
override string f() { return B; }
}
---
Error: function main.B.T!().f multiple overrides of same function
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #28 from Don clugd...@yahoo.com.au 2012-05-04 04:48:20 PDT --- (In reply to comment #27) (In reply to comment #26) There's no reason to doubt you are telling the truth, so this must be quite an interesting case of confirmation bias as you seem to have read only what doesn't infirm your hypothesis and glossed over everything that does. As an example, google for design by contract inheritance The literally FIRST hit takes to a slide deck, see http://goo.gl/544fU. There there is theory and examples on how contracts work. Andrei, those slides don't address the issue at all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8032] New: `mixin template` before virtual method with same method causes an error
http://d.puremagic.com/issues/show_bug.cgi?id=8032
Summary: `mixin template` before virtual method with same
method causes an error
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis verylonglogin@gmail.com 2012-05-04 16:04:08 MSD
---
This doesn't compile if `mixin template` is declared before virtual method `f`:
---
mixin template T() {
void f() { }
}
class A {
mixin T; // Named mixin causes the error too
void f() { }
}
class B : A {
override void f() { }
}
---
Error: class main.B use of main.A.f() hidden by B is deprecated
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #29 from Andrei Alexandrescu and...@metalanguage.com 2012-05-04
05:35:12 PDT ---
(In reply to comment #28)
The literally FIRST hit takes to a slide deck, see http://goo.gl/544fU.
There
there is theory and examples on how contracts work.
Andrei, those slides don't address the issue at all.
The issue as exemplified herein is:
class A {
void foo(int x) in { assert(x 0); } body {}
}
class B : A {
void foo(int x) in { assert(x -2); } body {}
}
void fizzbuzz(A a) {
a.foo(-1);
}
The question is, why does the code work when A's contract is in fact violated.
Slide 22-10 in that deck gives as example a method invert(). The base class has
precondition epsilon = 10^(– 6) and the derived class has precondition epsilon
= 10^(– 20). The surrounding slides explain rather copiously how a call to
invert against the derived class works even though the precondition of the base
class is violated (e.g. by passing epsilon = 10^(– 10). The example given in
the slides has a straightforward correspondence to the one above.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5028] Problem with named mixins in base class and derived class
http://d.puremagic.com/issues/show_bug.cgi?id=5028
Denis verylonglogin@gmail.com changed:
What|Removed |Added
CC||verylonglogin@gmail.com
--- Comment #2 from Denis verylonglogin@gmail.com 2012-05-04 16:51:24 MSD
---
The issue is that this doesn't compile:
---
mixin template T() { final void f() { } }
class A { mixin T ta; }
class B : A { mixin T tb; }
---
We need a general solution here. Looks like
---
class A { mixin T; }
class B : A { mixin T tb; }
---
and
---
class A { mixin T ta; }
class B : A { mixin T; }
---
and
---
class A { final void f() { } }
class B : A { mixin T tb; }
---
and
---
class A { mixin T ta; }
class B : A { final void f() { } }
---
should also compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #30 from Don clugd...@yahoo.com.au 2012-05-04 05:57:39 PDT ---
(In reply to comment #29)
(In reply to comment #28)
The literally FIRST hit takes to a slide deck, see http://goo.gl/544fU.
There
there is theory and examples on how contracts work.
Andrei, those slides don't address the issue at all.
The issue as exemplified herein is:
class A {
void foo(int x) in { assert(x 0); } body {}
}
class B : A {
void foo(int x) in { assert(x -2); } body {}
}
void fizzbuzz(A a) {
a.foo(-1);
}
The question is, why does the code work when A's contract is in fact violated.
Slide 22-10 in that deck gives as example a method invert(). The base class
has
precondition epsilon = 10^(– 6) and the derived class has precondition
epsilon
= 10^(– 20). The surrounding slides explain rather copiously how a call to
invert against the derived class works even though the precondition of the
base
class is violated (e.g. by passing epsilon = 10^(– 10). The example given in
the slides has a straightforward correspondence to the one above.
You are making a massive assumption here, which I don't see in the slides. The
assumption is that fizzbuzz gets access to B's weakened precondition.
I've looked all over the Eiffel website and haven't seen anything which implies
that. Rather, everything I read implies that it's a contract -- it's the
clients responsibility to ensure that the precondition is satisfied. fizzbuzz
doesn't have a contract with B, it doesn't even know that B exists.
fizzbuzz() clearly has a bug. It will fail if given an A which isn't actually a
B.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8020] std.stdio can't open UTF16 file names in Windows
http://d.puremagic.com/issues/show_bug.cgi?id=8020 --- Comment #4 from Oleg Kuporosov oleg.kuporo...@gmail.com 2012-05-04 06:05:24 PDT --- Dmitry, we should not assume the name string is in UTF8, it may be also some another 8-bit code page in being supported in Windows, like 125x and so on. Such encoding should be done by application itself. What I think is to have File/open/popen( wstring, string mode ) which should care about UTF16 names. Surprisingly I found some links in DMC includes to _wfopen receiving wchar_t which should exacly help here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8033] New: Named template mixins conflicts with unnamed
http://d.puremagic.com/issues/show_bug.cgi?id=8033
Summary: Named template mixins conflicts with unnamed
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis verylonglogin@gmail.com 2012-05-04 17:09:29 MSD
---
---
mixin template T() {
void f() { }
}
mixin T t;
mixin T;
void main() {
f();
}
---
Error: main.A.T!().f at main.d(2) conflicts with main.A.T!().f at main.d(2)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8034] New: Template mixins creates ambiguous virtual function
http://d.puremagic.com/issues/show_bug.cgi?id=8034
Summary: Template mixins creates ambiguous virtual function
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis verylonglogin@gmail.com 2012-05-04 17:17:42 MSD
---
This compiles but shouldn't:
---
mixin template T() {
void f() { }
}
class A {
mixin T;
mixin T;
}
class B : A {
override void f() { }
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #31 from Andrei Alexandrescu and...@metalanguage.com 2012-05-04 06:21:14 PDT --- (In reply to comment #30) You are making a massive assumption here, which I don't see in the slides. The assumption is that fizzbuzz gets access to B's weakened precondition. I've looked all over the Eiffel website and haven't seen anything which implies that. Rather, everything I read implies that it's a contract -- it's the clients responsibility to ensure that the precondition is satisfied. fizzbuzz doesn't have a contract with B, it doesn't even know that B exists. I understand the distinction, and how the slides doesn't make it clear that the precondition is dynamically bound. In fact the author found it so obvious as to be unnecessary to mention (generally in the OOP world all methods are dynamically bound unless expressly noted otherwise; C++ is an anomaly). The second hit, http://goo.gl/5r7BF, clarifies with the diagrams on slides 17, 18, 20 and with the associated text that client code interacts with the base class only. The ultimate proof would be to read Meyer's book on DbC (or the other one) and/or download the Eiffel compiler and compile an example. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8035] New: False hijacking error
http://d.puremagic.com/issues/show_bug.cgi?id=8035
Summary: False hijacking error
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: and...@metalanguage.com
--- Comment #0 from Andrei Alexandrescu and...@metalanguage.com 2012-05-04
07:01:06 PDT ---
Consider:
import std.regex, std.string;
void main() {
split(shello, regex([ \t,.;:?]+));
}
The compiler complains:
test.d(5): Error: std.regex.split(String,RegEx) if (isSomeString!(String)
isRegexFor!(RegEx,String)) at /Users/aalexandre/code/d/phobos/std/regex.d(6796)
conflicts with std.string.split at
/Users/aalexandre/code/d/phobos/std/string.d(70)
However, line 60 in std.string just aliases split to std.array.split. In turn,
std.array defines two split functions, neither of which accepts a regex in the
second position. So there is no potential hijacking.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2646] Named mixins and member functions
http://d.puremagic.com/issues/show_bug.cgi?id=2646 Denis verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #2 from Denis verylonglogin@gmail.com 2012-05-04 18:37:45 MSD --- Related NG thread: http://forum.dlang.org/thread/jo0lmj$4dp$1...@digitalmars.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8020] std.stdio can't open UTF16 file names in Windows
http://d.puremagic.com/issues/show_bug.cgi?id=8020 --- Comment #5 from Dmitry Olshansky dmitry.o...@gmail.com 2012-05-04 07:48:07 PDT --- (In reply to comment #4) Dmitry, we should not assume the name string is in UTF8, it may be also some another 8-bit code page in being supported in Windows, like 125x and so on. Such encoding should be done by application itself. Nope, char is UTF-8 codeunit period. See TDPL, language spec etc. Legacy one-byte encodings should be transfered in bytes/ubytes whatever. BTW NTFS is UTF-16 (or subset of it). What I think is to have File/open/popen( wstring, string mode ) which should care about UTF16 names. Surprisingly I found some links in DMC includes to _wfopen receiving wchar_t which should exacly help here. Then someone just needs rig current std.file to call toUTF16/toUTFz (see std.uni) and forward the result to the right _wfopen on win32. UTF-16 been the defacto standard in Windows for a looong time. This is all is just embarracing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8032] `mixin template` before virtual method with same method causes an error
http://d.puremagic.com/issues/show_bug.cgi?id=8032 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-05-04 08:55:36 PDT --- https://github.com/D-Programming-Language/dmd/pull/925 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8036] New: Zero-length static array of structs with elaborate destructor as struct or class field is rejected
http://d.puremagic.com/issues/show_bug.cgi?id=8036
Summary: Zero-length static array of structs with elaborate
destructor as struct or class field is rejected
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis verylonglogin@gmail.com 2012-05-04 19:57:07 MSD
---
---
struct S {
~this(){ }
}
struct S2 { // or class
S[0] s;
}
---
Error: this for ~this needs to be type S not type S[0u]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8038] New: #line which is in a double template instantiation doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8038
Summary: #line which is in a double template instantiation
doesn't work
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: youx...@gmail.com
--- Comment #0 from Hisayuki Mima youx...@gmail.com 2012-05-05 01:18:47 JST
---
template t(T){alias T t;}
t!(#line 10
t!(
int,
)
) i;
This code works well, but...
template t(T){alias T t;}
t!(
t!(#line 10
int,
)
) i;
this code cause syntax errors.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7893] Spec completely wrong for D variadic arguments on 64 bits
http://d.puremagic.com/issues/show_bug.cgi?id=7893 --- Comment #2 from github-bugzi...@puremagic.com 2012-05-04 10:39:11 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/71e4c9f7b3aef23b345fb541b1a91548f36e23c2 fix Issue 7893 - Spec completely wrong for D variadic arguments on 64 bits -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #32 from Stewart Gordon s...@iname.com 2012-05-04 10:38:33 PDT --- (In reply to comment #30) fizzbuzz() clearly has a bug. It will fail if given an A which isn't actually a B. Exactly. fizzbuzz is calling a method of A, not a method of B. As such, as I've already said, it must conform to A's API, but it is failing to do so. (In reply to comment #31) I understand the distinction, and how the slides doesn't make it clear that the precondition is dynamically bound. In fact the author found it so obvious as to be unnecessary to mention So it could have been just an oversight for all we know. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7893] Spec completely wrong for D variadic arguments on 64 bits
http://d.puremagic.com/issues/show_bug.cgi?id=7893 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8032] `mixin template` before virtual method with same method causes an error
http://d.puremagic.com/issues/show_bug.cgi?id=8032 --- Comment #2 from github-bugzi...@puremagic.com 2012-05-04 11:11:24 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/741b88c6a81320237c0a3cdd312238d0fcb20e9e fix Issue 8032 - `mixin template` before virtual method with same method causes an error https://github.com/D-Programming-Language/dmd/commit/b488853f4d3617945851d5d0a2ac20ccb7dab631 Merge pull request #925 from 9rnsr/fix8032 Issue 8032 - `mixin template` before virtual method with same method causes an error -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #33 from Walter Bright bugzi...@digitalmars.com 2012-05-04
11:42:40 PDT ---
(In reply to comment #32)
(In reply to comment #30)
fizzbuzz() clearly has a bug. It will fail if given an A which isn't
actually a
B.
Exactly. fizzbuzz is calling a method of A, not a method of B. As such, as
I've already said, it must conform to A's API, but it is failing to do so.
First off, if fizzbuzz() is passed an A, then it will (correctly) fail. Where's
the bug in the contract design? Secondly, the -1 may not be a literal, it may
be a value computed from B, as in:
class A {
void foo(int x) in { assert(x 0); } body {}
int bar() { return 1; }
}
class B : A {
void foo(int x) in { assert(x -2); } body {}
int bar() { return -1; }
}
void fizzbuzz(A a) {
a.foo(bar());
}
So, clearly is NOT required that a.foo(arg) pass A.foo's contract.
The design of OOP and contracts is sound. Correct programs will pass, and
incorrect programs will fail. I don't see any corner cases otherwise.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8039] `scoped` doesn't call any elaborate destructors for struct fields
http://d.puremagic.com/issues/show_bug.cgi?id=8039 --- Comment #1 from Denis verylonglogin@gmail.com 2012-05-04 23:24:11 MSD --- https://github.com/D-Programming-Language/phobos/pull/569 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6580] scoped classes are aligned incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=6580 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com 2012-05-04 23:39:57 MSD --- https://github.com/D-Programming-Language/phobos/pull/570 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8040] New: writeln(null) too
http://d.puremagic.com/issues/show_bug.cgi?id=8040
Summary: writeln(null) too
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-05-04 12:55:24 PDT ---
Problem found by Ali �ehreli.
D2 code:
import std.stdio: writeln;
class Foo {}
struct Bar {}
void main() {
Foo f = null;
writeln(f);
Bar* b = null;
writeln(b);
writeln(null);
}
Expected output similar to:
cast(Foo)null
cast(Bar*)null
null
DMD 2.056 prints null in the first two writeln, and gives errors for the
third one:
...\dmd2\src\phobos\std\stdio.d(1562): Error: undefined identifier 'length'
...\dmd2\src\phobos\std\stdio.d(1562): Error: undefined identifier 'ptr', did
you mean 'template tr(C1,C2,C3,C4 = immutable(char))'?
test.d(9): Error: template instance std.stdio.writeln!(typeof(null)) error
instantiating
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4070] prefix const on member functions considered confusing
http://d.puremagic.com/issues/show_bug.cgi?id=4070 --- Comment #5 from bearophile_h...@eml.cc 2012-05-04 13:05:39 PDT --- Symmetry is good in a language, because it makes the compiler smaller, the language manuals smaller, and makes it simpler for programers to learn the language. But breaking symmetry is acceptable if this helps avoid bugs. A thread where Manu has found a problem caused by const prefixing: http://forum.dlang.org/thread/CAOC+-J9Pw31mMSSnCR4kC89siNYkg27Lm7CNk7r+prRo+DQq=q...@mail.gmail.com I invite people to add more cases in this thread. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #34 from Stewart Gordon s...@iname.com 2012-05-04 13:27:50 PDT ---
(In reply to comment #33)
OK, so there's this issue. It may also be a documented guarantee that the
return value from bar is a valid argument for foo.
But you could still argue that the call is in breach of A's API and therefore
the code is incorrect. To be correct, the in contract for A.foo would have to
be something like
in { assert(x 0 || x == bar()); }
But since enforcing this now is a potentially breaking change, I can now see a
case for leaving the behvaiour as it is.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #35 from Walter Bright bugzi...@digitalmars.com 2012-05-04
13:41:50 PDT ---
(In reply to comment #34)
But you could still argue that the call is in breach of A's API and therefore
the code is incorrect.
Again, this is NOT true. The type of the argument is not statically A, it is a
polymorphic type A.
If an instance of A is passed, then the call to foo(-1) will fail. Please try
it and see for yourself. There is no hole in the system.
To be correct, the in contract for A.foo would have to
be something like
in { assert(x 0 || x == bar()); }
But since enforcing this now is a potentially breaking change, I can now see a
case for leaving the behvaiour as it is.
You are still seeing this as a bug in the OOP design. It is not. The design is
sound and correct.
If you still disagree, please write a code sample that asserts when it should
not, or passes when it must not, compile it and run it, and post it here.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #36 from Stewart Gordon s...@iname.com 2012-05-04 13:49:11 PDT --- (In reply to comment #35) snip Again, this is NOT true. The type of the argument is not statically A, it is a polymorphic type A. Why do you consider the contracts of a method to be NOT part of the API? Because Bertrand considers it so, or for some other reason? If an instance of A is passed, then the call to foo(-1) will fail. Please try it and see for yourself. I never doubted that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7982] iota broken when start and end are unsigned and step is negative.
http://d.puremagic.com/issues/show_bug.cgi?id=7982 Brad Anderson e...@gnuk.net changed: What|Removed |Added Keywords||pull --- Comment #1 from Brad Anderson e...@gnuk.net 2012-05-04 14:05:29 PDT --- https://github.com/D-Programming-Language/phobos/pull/566 Better solutions welcome. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #37 from Walter Bright bugzi...@digitalmars.com 2012-05-04 14:13:50 PDT --- (In reply to comment #36) (In reply to comment #35) snip Again, this is NOT true. The type of the argument is not statically A, it is a polymorphic type A. Why do you consider the contracts of a method to be NOT part of the API? This is not what I am considering. I am saying that A is a polymorphic type, not a static type. The contracts that apply depend on the runtime polymorphic type, not the static type. Because Bertrand considers it so, or for some other reason? I am not using argument by authority. Meyer explains it quite well, step by step, in his book I recommended to you. The behavior is an inevitable consequence of the fundamental principles of OOP. That is why it is not a matter of opinion. If an instance of A is passed, then the call to foo(-1) will fail. Please try it and see for yourself. I never doubted that. Then I am lost as to what you think is broken in the design. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #38 from Stewart Gordon s...@iname.com 2012-05-04 14:30:40 PDT --- (In reply to comment #37) Then I am lost as to what you think is broken in the design. In how many different ways does the same thing need to be explained to you before you understand it? If a subclass introduces a new method, that new method doesn't exist from the base class's point of view. In the same way, if a subclass introduces new legal arguments to a method, those new legal arguments don't exist from the base class's point of view. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7995] regression(2.059): D runtime initialization from C fails on OSX in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=7995 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #1 from Jacob Carlborg d...@me.com 2012-05-04 14:33:46 PDT --- I would guess the reason for this is _d_osx_image_init2 is not called in rt_init. main should really call rt_init do avoid code duplication. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #39 from Walter Bright bugzi...@digitalmars.com 2012-05-04 14:46:11 PDT --- Please write a piece of code that asserts when it should not, or passes when it should not, compile it, verify this incorrect behavior, and post it here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #40 from Stewart Gordon s...@iname.com 2012-05-04 14:52:44 PDT --- (In reply to comment #39) Please write a piece of code that asserts when it should not, or passes when it should not, compile it, verify this incorrect behavior, and post it here. Timon has already done this and posted it in the description when filing this report in the first place. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6329] Out of range exceptions not thrown in certain cases
http://d.puremagic.com/issues/show_bug.cgi?id=6329 SomeDude lovelyd...@mailmetrash.com changed: What|Removed |Added CC||lovelyd...@mailmetrash.com --- Comment #13 from SomeDude lovelyd...@mailmetrash.com 2012-05-04 15:01:42 PDT --- The problem seems solved with 2.059 Win32. I can see the errors with or without -g. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8041] New: __gshared/static problem
http://d.puremagic.com/issues/show_bug.cgi?id=8041
Summary: __gshared/static problem
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-05-04 15:09:57 PDT ---
I am not sure, I think this is valid code:
struct Foo {
__gshared static int x;
}
void main() {
__gshared Foo f; // line 5
}
But DMD 2.060alpha gives the error:
test.d(5): Error: non-constant expression f = 0
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8042] New: extern(C) on structs can cause stack corruption with opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=8042 Summary: extern(C) on structs can cause stack corruption with opEquals Product: D Version: unspecified Platform: x86 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: spunit...@yahoo.com --- Comment #0 from Robert DaSilva spunit...@yahoo.com 2012-05-04 15:11:58 PDT --- Created an attachment (id=1100) test case It looks like what's happening is the extern(C) on the struct is affecting the hidden helper function __xopEquals use by the typeinfo. Once I figured out what was wrong, it was easy enough to make sure the strut was extern(C), but actually figure out what was going wrong wasn't easy. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #41 from Walter Bright bugzi...@digitalmars.com 2012-05-04 15:18:08 PDT --- (In reply to comment #40) (In reply to comment #39) Please write a piece of code that asserts when it should not, or passes when it should not, compile it, verify this incorrect behavior, and post it here. Timon has already done this and posted it in the description when filing this report in the first place. Example #1 expects behavior based on the static type, which is not polymorphic OOP at all. Of course x.foo() should check B's widened interface, because: x is a B! The example's rationale is completely invalid. Please read Meyer's book. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #42 from Stewart Gordon s...@iname.com 2012-05-04 15:27:45 PDT --- (In reply to comment #41) Example #1 expects behavior based on the static type, which is not polymorphic OOP at all. True, but it is what this enhancement request is all about. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6432] Compilation doesn't terminate on a recursive mixin error
http://d.puremagic.com/issues/show_bug.cgi?id=6432 SomeDude lovelyd...@mailmetrash.com 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 6838] Covariant return types don't work with static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6838 SomeDude lovelyd...@mailmetrash.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from SomeDude lovelyd...@mailmetrash.com 2012-05-04 16:06:07 PDT --- Code returns a sound compilation error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6896] ICE(glue.c !vthis-csym): on method with alias this access
http://d.puremagic.com/issues/show_bug.cgi?id=6896 SomeDude lovelyd...@mailmetrash.com 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 8036] Zero-length static array of structs with elaborate destructor as struct or class field is rejected
http://d.puremagic.com/issues/show_bug.cgi?id=8036 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-05-04 16:35:16 PDT --- https://github.com/D-Programming-Language/dmd/pull/926 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8043] New: DMD Crash on undefined identifier
http://d.puremagic.com/issues/show_bug.cgi?id=8043
Summary: DMD Crash on undefined identifier
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-05-04
16:39:22 PDT ---
void main()
{
enum B = 1;
enum a = [b];
}
I get the ol' dialog box:
---
dmd.exe - Application Error
---
The instruction at 0x0044b049 referenced memory at 0x. The memory
could not be read.
Seems to only happen with enums and an array of an undefined symbol.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #43 from Walter Bright bugzi...@digitalmars.com 2012-05-04 17:40:19 PDT --- (In reply to comment #42) True, but it is what this enhancement request is all about. Breaking correct OOP behavior is not an enhancement. It will not break existing wrong-but-just-happens-to-work programs, it will break *correct* programs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8043] DMD Crash on undefined identifier
http://d.puremagic.com/issues/show_bug.cgi?id=8043 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WORKSFORME --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-05-04 17:43:52 PDT --- Fails on 2.059, but works correctly on 2.060 head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #44 from Stewart Gordon s...@iname.com 2012-05-04 17:50:19 PDT --- (In reply to comment #43) (In reply to comment #42) True, but it is what this enhancement request is all about. Breaking correct OOP behavior is not an enhancement. But going by comment 26, there is no breakage of correct OOP behaviour involved. So how is this relevant? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #45 from Walter Bright bugzi...@digitalmars.com 2012-05-04 18:18:11 PDT --- (In reply to comment #44) But going by comment 26, there is no breakage of correct OOP behaviour involved. So how is this relevant? This has already been covered. We're going in circles. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7900] CTFE Internal error with -inline and associative arrays
http://d.puremagic.com/issues/show_bug.cgi?id=7900 --- Comment #4 from brian-sch...@cox.net 2012-05-04 18:37:02 PDT --- Using DMD from git (b488853f4d3617945851d5d0a2ac20ccb7dab631), the error message now shows: tmp.d(21): Error: CTFE internal error: illegal value TOK232.children dmd: interpret.c:6884: void VarDeclaration::setValue(Expression*): Assertion `isCtfeValueValid(newval)' failed. Aborted The corrupted output is now gone, so that's a good thing. Test case still compiles without -inline and fails when it is present. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8044] New: Print names, not casted values when using enum template parameter
http://d.puremagic.com/issues/show_bug.cgi?id=8044
Summary: Print names, not casted values when using enum
template parameter
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-05-04
20:33:56 PDT ---
enum Enum { Foo, Bar }
void test(Enum en)()
if(0)
{
}
void main()
{
test!(Enum.Bar)();
}
test.d(11): Error: template instance test!(cast(Enum)1) test!(cast(Enum)1) does
not match template declaration test(Enum en) if (0)
test.d(11): Error: function expected before (), not test!(cast(Enum)1) of type
void
This is really awful because when you have over a few dozen fields in an enum
you end up having to count the fields to figure out which enum value was
actually used when instantiating the template. (Either that or having to insert
a to!string call just for debugging).
The above errors should be:
test.d(11): Error: template instance test!(Enum.Bar) test!(Enum.Bar) does not
match template declaration test(Enum en) if (0)
test.d(11): Error: function expected before (), not test!(Enum.Bar) of type
void
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8045] New: Postblit should be called on function call initilalizer that returns ref
http://d.puremagic.com/issues/show_bug.cgi?id=8045
Summary: Postblit should be called on function call
initilalizer that returns ref
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-05-04 22:17:26 PDT ---
void main()
{
struct S
{
int a;
this(this)
{
++a;
}
}
ref S f(ref S s)
{
return s;
}
S s1 = S(10);
S s2 = f(s1); // postblit should be called, but doesn't
assert(s2.a == 11);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #46 from Don clugd...@yahoo.com.au 2012-05-04 22:58:38 PDT ---
(In reply to comment #45)
(In reply to comment #44)
But going by comment 26, there is no breakage of correct OOP behaviour
involved. So how is this relevant?
This has already been covered. We're going in circles.
Walter, you haven't understood this at all. None of us have claimed that the
program ever gets into a wrong state. Let me try another way.
Given a module which consists of:
--
struct F {
void foo(int n) in { assert( n 0); } body {}
}
void xyzzy(F f)
{
f.foo(-1);
}
--
A theorem prover, or even a compiler that did basic range checking for
preconditions, should raise an error at compile time. Not at run time when it's
actually called with an F, but at compile time. Nothing controversial there.
Now, change F from a struct to a class. We believe that the code should still
fail to compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
