[Issue 8011] BigInt ++ and -- do wrong thing on negative numbers
http://d.puremagic.com/issues/show_bug.cgi?id=8011 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8020] New: std.stdio can't open UTF16 file names in Windows
http://d.puremagic.com/issues/show_bug.cgi?id=8020 Summary: std.stdio can't open UTF16 file names in Windows Product: D Version: unspecified Platform: All OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: oleg.kuporo...@gmail.com --- Comment #0 from Oleg Kuporosov oleg.kuporo...@gmail.com 2012-05-03 00:02:15 PDT --- File() and p/open() assume to receive only ASCII or UTF8 file names. Windows is supporting UTF16 file systems so portability is limited only by ASCII names. We probably may have these API receiving wstring also to satisfy this enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8016] (Regression git) Methods defined in external object files when template alias parameter is involved
http://d.puremagic.com/issues/show_bug.cgi?id=8016 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2012-05-03 00:39:41 PDT --- As for bug 7745, with D2, it doesn't need -release -inline. -- 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 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-05-03 00:51:22 PDT --- UTF8 supports the full unicode set, not just ASCII. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8021] New: BigInt division bug
http://d.puremagic.com/issues/show_bug.cgi?id=8021
Summary: BigInt division bug
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: yuri.musashi.miwa.tam...@gmail.com
--- Comment #0 from Musashi Tamura yuri.musashi.miwa.tam...@gmail.com
2012-05-03 01:06:48 PDT ---
In dmd 2.059,
the program below won't terminate.
import std.stdio, std.bigint;
void main() {
BigInt n = BigInt(2) / BigInt(0);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5570 James Miller ja...@aatch.net changed: What|Removed |Added CC||ja...@aatch.net --- Comment #14 from James Miller ja...@aatch.net 2012-05-03 01:13:16 PDT --- Throwing my vote in for this one, this is pretty much stopping me from using DMD64 for my C bindings. For the record, LDC works in this case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8022] New: BigInt division bug (2)
http://d.puremagic.com/issues/show_bug.cgi?id=8022
Summary: BigInt division bug (2)
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: yuri.musashi.miwa.tam...@gmail.com
--- Comment #0 from Musashi Tamura yuri.musashi.miwa.tam...@gmail.com
2012-05-03 01:20:17 PDT ---
(in dmd 2.059)
import std.stdio, std.bigint;
void main() {
BigInt n = BigInt(2) / BigInt(-3);
writeln(n);
writeln(n == 0);
}
output:
-0
false
I think correct output is 0 and true.
--
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 #12 from deadalnix deadal...@gmail.com 2012-05-03 01:43:42 PDT ---
(In reply to comment #11)
The current specification is flawed. It have nothing to do with how
inheritance work (and I could assure you I know what I'm talking about, and
I'm also pretty sure Timon knows also).
Mistakes happen to the best of us. In this case the specification is correct
and the bug report is in error. Derived classes may require less and provide
more, which in contract lingo translates into weaker in contracts and
stronger�out contracts. This is not a matter in which reasonable people may
disagree and not a matter of opinion.
I think you misunderstood what we are talking about here, as Walter is.
Nobody here discussed teh fact that in contract shouldn't become weaker when
inherited. This is, indeed, what corect OO design is.
What is discussed here is, with all details.
class A {
void foo() in { ... } body { ... }
}
class B : A {
override void foo() in { ... } body { ... }
}
then, let's consider :
fizbuzzA(A a) {
a.foo(); // A.foo's in contract is valid
}
fizzbuzzB(B b) {
b.foo(); // (A.foo OR B.foo)'s in contract is valid
}
The point is that B.foo's in contract loosen A.foo's in contract. And fizzbuzzA
have no knowledge of the fact that a subclass of A's instance can be passed.
So, if fizzbuzzA use foo with parameter that validate A.foo's in contract, but
not B.foo's in contract, it is an error. fizzbuzzA have no knowledge of the
runtime type of a, so shouldn't pass argument to foo that is invalid according
to A.foo's in contract. If it does, it means that fizzbuzzA is bugguy, or does
know about that fact that a isn't of type A, which is exactly what we DON'T
want when doing OOP.
It is Liskov substitution principle, any object of type B can be substituted to
an object of type A without the code using the object knowing about it. It is
probably the most important thing in OOP.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8016] (Regression git) Methods defined in external object files when template alias parameter is involved
http://d.puremagic.com/issues/show_bug.cgi?id=8016 --- Comment #2 from Don clugd...@yahoo.com.au 2012-05-03 02:04:54 PDT --- Here's what happens. When parsing m2, it imports m1. The static assert forces it to run semantic on f(). This instantiates template t. t gets added to the list of instantiated templates *of module m2*. Before the fix for bug 2962 was made, template t was written to m2.o with weak linkage. This was strictly unnecessary, but relatively harmless because of the weak linkage. But the template that was written may have been wrong, if it hit bug 2962. Now that bug 2962 is fixed, it writes f. This pull request changes it so that it only writes f if it is part of a template, and will therefore have weak linkage. That still fixes all test cases in bug 2962. https://github.com/D-Programming-Language/dmd/pull/920 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7584] contract checking is too conservative for inherited contracts
http://d.puremagic.com/issues/show_bug.cgi?id=7584 --- Comment #7 from timon.g...@gmx.ch 2012-05-03 02:20:30 PDT --- (In reply to comment #6) Out contracts are anded together, meaning that *all* out contracts must pass in an inheritance hierarchy. Out contracts in overriding functions do not override the out contract in the overridden function, nor are they at all associated with any in contracts. The point here was that they should be. Why should the method work hard to satisfy the postcondition, if the caller fails to satisfy the corresponding precondition? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6296] ICE(glue.c): invalid template instantiated in is(typeof()).
http://d.puremagic.com/issues/show_bug.cgi?id=6296 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #20 from Don clugd...@yahoo.com.au 2012-05-03 02:53:13 PDT --- *** This issue has been marked as a duplicate of issue 4269 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4269] Regression(2.031): invalid type accepted if evaluated while errors are gagged
http://d.puremagic.com/issues/show_bug.cgi?id=4269 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #25 from Don clugd...@yahoo.com.au 2012-05-03 02:53:14 PDT --- *** Issue 6296 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 7955] Nested function error in sort with lambda template but not with a lambda
http://d.puremagic.com/issues/show_bug.cgi?id=7955
Denis verylonglogin@gmail.com changed:
What|Removed |Added
CC||verylonglogin@gmail.com
--- Comment #1 from Denis verylonglogin@gmail.com 2012-05-03 14:16:10 MSD
---
Reduced testcase:
---
void f(alias fun)() { }
void g(T)() {
f!(a = a)();
}
void main() {
g!int();
g!long();
}
---
Error: function main.g!(int).g.f!(__lambda2).f is a nested function and cannot
be accessed from main.g!(long).g
Workaround: explicitly define lambda type: `(int a) = a`.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8016] (Regression git) Methods defined in external object files when template alias parameter is involved
http://d.puremagic.com/issues/show_bug.cgi?id=8016 --- Comment #3 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-05-03 03:21:07 PDT --- https://github.com/D-Programming-Language/dmd/pull/920 Looks like this test case is exposing more bugs than we were aware of! This pull request fixes the original problem I had (compiling tango CDGC), which is the test case without the forceSemantic() trick. Using the forceSemantic() trick doesn't work in D1 but doesn't look like a regression, at least is present in 1.070 and 1.071. The patch only fixes the problem partially though, with the patch you don't get the multiple definition error but you get an undefined reference error instead, so is a step forward but not a fix. But again, this is not a regression in D2, the problem is present at least before the fix for 2962. I'll report another bug with the D1-only bug that's fixed by this pull request, so we can close that one when the pull is merged, but can keep this one open (but without the regression severity). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7917] [ICE] (toir.c 178) with nested function
http://d.puremagic.com/issues/show_bug.cgi?id=7917
Denis verylonglogin@gmail.com changed:
What|Removed |Added
CC||verylonglogin@gmail.com
--- Comment #8 from Denis verylonglogin@gmail.com 2012-05-03 14:25:30 MSD
---
This issue is derived from Issue 7955. Everything you need to create this issue
from Issue 7955 is to wrap lambda template in a nested function.
Code from Issue 7955 comment #1 with addition of `spam`:
---
void f(alias fun)() { }
void g(T)() {
void spam() {
f!(a = a)();
}
}
void main() {
g!int();
g!long();
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7413] Vector literals don't work
http://d.puremagic.com/issues/show_bug.cgi?id=7413 --- Comment #16 from Manu turkey...@gmail.com 2012-05-03 03:25:43 PDT --- (In reply to comment #15) (In reply to comment #14) (In reply to comment #13) (In reply to comment #12) (In reply to comment #11) Haven't done the special case optimizations for constant loading. No problem, I'm using GDC anyway which might detect those in the back end. An efficient implementation would certainly use at least an xor for 0 initialisation, and the other tricks will get different mileage depending on the length of the pipeline surrounding. Not accessing memory is always better if there are pipeline cycles to soak up the latency. The -1 trick is always worth doing, I think. Agner Fog has a nice list in his optimisation manuals, but the only ones _always_ worth doing are the 0 and -1 integer cases, and the 0.0 floating point case (also using xor). If the compiler knows anything about the pipeline around the code, it should be able to make the best choice about the others. My guess is that it's pretty rare that the alternative sequences are favoured just on the basis of the pipeline, since MOVDQA only uses a load port, and nothing else. Especially on Sandy Bridge or AMD, where there are two load ports. So I doubt there's much benefit to be had. By contrast, if there's _any_ chance of a cache miss, they'd be a huge win, but unfortunately that's far beyond the compiler's capabilities. And that's precisely my reasoning. If the compiler knows the state of the pipeline around the load, and there aren't conflicts, ie, can slip the instructions in for free between other pipeline stalls, then generating an immediate is always better than touching memory. Schedulers usually do have this information while performing code generation, so it may be possible. These sorts of considerations are obviously much more critical for non-x86 based architectures though, as with basically all optimisations ;) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4432] DMD r575 won't build on Linux in debug mode: undefined reference to obj_long
http://d.puremagic.com/issues/show_bug.cgi?id=4432 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-05-03 03:32:45 PDT --- This was fixed 2 million years ago. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8023] New: (Regression git) Methods defined in external object files when template alias parameter is involved
http://d.puremagic.com/issues/show_bug.cgi?id=8023
Summary: (Regression git) Methods defined in external object
files when template alias parameter is involved
Product: D
Version: D1
Platform: All
OS/Version: All
Status: NEW
Keywords: pull, wrong-code
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: leandro.lucare...@sociomantic.com
CC: clugd...@yahoo.com.au
Depends on: 8016
--- Comment #0 from Leandro Lucarella leandro.lucare...@sociomantic.com
2012-05-03 03:31:28 PDT ---
+++ This issue was initially created as a clone of Issue #8016 +++
This looks like a reincarnation of bug 7745, but is different.
Testcase:
m1.d
---
module m1;
import m2;
private void t(alias Code)()
{
return Code();
}
void f()
{
t!( () { } )();
}
---
m2.d
---
module m2;
import m1;
---
dmd -c -inline -release -g m2.d nm m2.o | grep '_D2m11fFZv$'
T _D2m11fFZv
Which means that _D2m11fFZv (AKA m1.f()) is included in the text
(code) section of m2.o, but it shouldn't, it should only be in m1.d (which I
didn't even compile), otherwise when linking both m1.o and m2.o you'll get a
multiple definition error. Symbol _D2m11fFZv should be not present at all in
that object file.
Please note that the compiler flags -inline -release has to be used to
reproduce the bug, removing either makes it go away. -O is irrelevant.
Confirmed in both 32 and 64 bits.
This regression was introduced by commit fix Issue 2962 - ICE(glue.c) or bad
codegen passing variable as template value parameter:
D1: https://github.com/D-Programming-Language/dmd/commit/d5a33a1
This pull request (for D2, expect a small conflict when merging), fixes the
problem:
https://github.com/D-Programming-Language/dmd/pull/920
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8016] (Regression git) Methods defined in external object files when template alias parameter is involved
http://d.puremagic.com/issues/show_bug.cgi?id=8016 --- Comment #4 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-05-03 03:45:02 PDT --- Added bug 8023. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8016] (Regression git) 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 Keywords|pull| Severity|regression |normal -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7584] contract checking is too conservative for inherited contracts
http://d.puremagic.com/issues/show_bug.cgi?id=7584 --- Comment #8 from deadalnix deadal...@gmail.com 2012-05-03 04:18:22 PDT --- (In reply to comment #6) Out contracts are anded together, meaning that *all* out contracts must pass in an inheritance hierarchy. Out contracts in overriding functions do not override the out contract in the overridden function, nor are they at all associated with any in contracts. What you have here is, in fact, over restrictive to ensure OOP expectations. With both your proposal and Timon's D is fine in regard of OOP. Now, Timon's proposal does allow more than the current behavior (and still allow the current behavior). You have to see it as a generalization of an over restrictive solution. -- 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 #1 from Leandro Lucarella leandro.lucare...@sociomantic.com
2012-05-03 04:22:06 PDT ---
Add a test case for this bug. Even when is not reproducible in D2 right now,
maybe is a good idea to have the test case anyway so it doesn't fail in the
future as D1 does now.
https://github.com/D-Programming-Language/dmd/pull/922
This includes also this test case, which is also a regression and it's fixed by
the pull request. This testcase doesn't need -inline -release to be reproduced
though!
m1.d
---
module m1;
import m2;
private void t(alias Code)()
{
return Code();
}
void f()
{
t!( () { } )();
}
bool forceSemantic()
{
f();
return true;
}
static assert(forceSemantic());
---
m2.d
---
module m2;
import m1;
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5499] ICE(toir.c): delegate as alias template parameter, only with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=5499
Leandro Lucarella leandro.lucare...@sociomantic.com changed:
What|Removed |Added
CC||leandro.lucarella@sociomant
||ic.com
--- Comment #6 from Leandro Lucarella leandro.lucare...@sociomantic.com
2012-05-03 04:36:04 PDT ---
Another simpler test case, or is this another bug?
---
void foo(alias f)() {
f();
}
void bar() {
foo!({})();
}
void main() {
bar();
}
---
m1.d(1): Error: function m1.bar.foo!(delegate void()
{
}
).foo is a nested function and cannot be accessed from main
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5499] ICE(toir.c): delegate as alias template parameter, only with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=5499
--- Comment #7 from Leandro Lucarella leandro.lucare...@sociomantic.com
2012-05-03 04:36:34 PDT ---
(In reply to comment #6)
Another simpler test case, or is this another bug?
---
void foo(alias f)() {
f();
}
void bar() {
foo!({})();
}
void main() {
bar();
}
---
m1.d(1): Error: function m1.bar.foo!(delegate void()
{
}
).foo is a nested function and cannot be accessed from main
Maybe is another bug because this is D1 only.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5499] ICE(toir.c): delegate as alias template parameter, only with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=5499 --- Comment #8 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-05-03 04:37:47 PDT --- But the testcases provided here compiles in current dmd2! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4504] ICE(toir.c) nested function passed by alias to nested member function
http://d.puremagic.com/issues/show_bug.cgi?id=4504 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|RESOLVED|REOPENED Version|D1 D2 |D1 Resolution|WORKSFORME | --- Comment #13 from Don clugd...@yahoo.com.au 2012-05-03 04:49:17 PDT --- The ICE still happens on D1.074 and D1 git head. Reopening and marking as D1 only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5778] Missing attributes.
http://d.puremagic.com/issues/show_bug.cgi?id=5778 Oleg Kuporosov oleg.kuporo...@gmail.com changed: What|Removed |Added CC||oleg.kuporo...@gmail.com --- Comment #2 from Oleg Kuporosov oleg.kuporo...@gmail.com 2012-05-03 04:53:08 PDT --- Per date there is no description for immutable, share and inout attributes on http://dlang.org/attribute.html . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8024] New: Template alias parameter is fail to compile when -inline is used
http://d.puremagic.com/issues/show_bug.cgi?id=8024
Summary: Template alias parameter is fail to compile when
-inline is used
Product: D
Version: D1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: leandro.lucare...@sociomantic.com
--- Comment #0 from Leandro Lucarella leandro.lucare...@sociomantic.com
2012-05-03 05:07:59 PDT ---
---
void foo(alias f)() {
f();
}
void bar() {
foo!({})();
}
void main() {
bar();
}
---
dmd -inline -c m1.d
m1.d(1): Error: function m1.bar.foo!(delegate void()
{
}
).foo is a nested function and cannot be accessed from main
Pretty similar to bug 5499 but not the same as the failures are so different.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5499] ICE(toir.c): delegate as alias template parameter, only with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=5499 Leandro Lucarella leandro.lucare...@sociomantic.com changed: What|Removed |Added See Also||http://d.puremagic.com/issu ||es/show_bug.cgi?id=8024 --- Comment #9 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-05-03 05:08:59 PDT --- Added a new bug 8024 for the case that only fails to 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 #13 from Andrei Alexandrescu and...@metalanguage.com 2012-05-03 07:05:18 PDT --- I apologize but I still think the confusion goes the other way. A good way to arbiter this is to peruse the literature on the subject, as Walter suggested. If going through a book has too much overhead, online articles and presentations should work, too. I can't afford to do much more explaining than essentially reciting material that's out there. For example I'd recommend this: http://www.cs.ucsb.edu/~bultan/courses/272-F08/lectures/Contract.ppt. Slides 19 and 20 should clarify the matter. -- 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 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #3 from Dmitry Olshansky dmitry.o...@gmail.com 2012-05-03 07:33:42 PDT --- I assumed it just transcodes UTF-8 into UTF-16 before trying to contact the OS on win32. Apparently that's not the case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7584] contract checking is too conservative for inherited contracts
http://d.puremagic.com/issues/show_bug.cgi?id=7584 --- Comment #10 from timon.g...@gmx.ch 2012-05-03 08:53:53 PDT --- (In reply to comment #9) (In reply to comment #0) IIRC, this is how contract inheritance works in Spec#. Spec# is (ahead of) state of the art in this area. According to my reading of http://http://research.microsoft.com/en-us/um/people/leino/papers/krml136.pdf, page 9, paragraph 1, Spec# does not allow overriding of preconditions so it can't be used here as an example. This seems to be correct. Thank you for looking it up. -- 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 #14 from deadalnix deadal...@gmail.com 2012-05-03 10:45:19 PDT ---
(In reply to comment #13)
I apologize but I still think the confusion goes the other way. A good way to
arbiter this is to peruse the literature on the subject, as Walter suggested.
If going through a book has too much overhead, online articles and
presentations should work, too. I can't afford to do much more explaining than
essentially reciting material that's out there. For example I'd recommend
this:
http://www.cs.ucsb.edu/~bultan/courses/272-F08/lectures/Contract.ppt. Slides
19
and 20 should clarify the matter.
I did read your document with attention, and looked for some other resources
today. That arguments given in such documents validate both the current state
of thing and the proposed new behavior.
In fact, I have failed to find any documentation/article/whatever about the
corner case where both behavior differs.
In other terms, as it seems that the corner case hasn't been considered, the
proposed solution is *A* solution and not *THE* solution. As, according to
given arguments I have found in literature, both behavior are good.
If I restate arguments they goes like this :
- B can be written way after fizzbuzzA, so shouldn't be able to provide an in
contract that break it.
- Instance of B can be passed to any code that expect instance of A, so B in
contracts can only loosen contract provided by A, not restrict them.
I think we all agree on such points. I think we can all agree also that both
current behavior and proposed behavior satisfy constraints expressed here.
The only case where things differs is the one given as example above. Let's
remove the ... to make it fully explicit.
class A {
void foo(int x) in { assert(x 0); } body {}
}
class B : A {
void foo(int x) in { assert(x -2); } body {}
}
and the function
void fizzbuzz(A a) {
a.foo(-1);
}
If I do fizzbuzz(new B()); The current behavior will not raise any error. But,
as we see in fizzbuzz's body, it doesn't because the object is of type B, not
of type A, because any other instances of subtypes of A or A can cause the
fizzbuzz function to fail.
We conclude that the fizzbuzz function is only correct if it DOES KNOW that it
is manipulating object of type B, because operation done are invalid on object
of type A.
The erratic behavior of fizzbuzz will not be spotted if I pass an instance of B
to fizzbuzz. Still, the code is flawed and waiting to explode any time in the
future. The whole point of contract is to spot such a situation.
For valid code, both behavior allow the same thing exactly. The proposed
behavior allow to spot MORE problems EARLIER, and it is something you want.
The only reason fizzbuzz here is correct if because the programmer KNOW only
instances of B will be passed to fizzbuzz.
I may be wrong, but I'd be happy to discuss that specific case, instead of
relying on documentation that do not talk about it. I failed in finding
documentation about that specific corner case.
--
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 #15 from Walter Bright bugzi...@digitalmars.com 2012-05-03
11:07:27 PDT ---
fizbuzzA(A a) {
a.foo(); // A.foo's in contract is valid
}
If an instance of B is passed to fizbuzzA, then the a.foo() will call B.foo(),
and either A.foo's in contract or B.foo's in contract must be valid.
There is no error or invalid corner case here.
I suspect that you think the contracts are checked based on static typing -
they are not, they are done using the virtual type.
--
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 --- Comment #7 from github-bugzi...@puremagic.com 2012-05-03 11:55:02 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 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #16 from Don clugd...@yahoo.com.au 2012-05-03 11:56:47 PDT ---
(In reply to comment #15)
fizbuzzA(A a) {
a.foo(); // A.foo's in contract is valid
}
If an instance of B is passed to fizbuzzA, then the a.foo() will call B.foo(),
and either A.foo's in contract or B.foo's in contract must be valid.
There is no error or invalid corner case here.
I suspect that you think the contracts are checked based on static typing -
they are not, they are done using the virtual type.
This is the issue. WHY are they done based on the virtual type?
Checking the contracts based on static typing would detect logical errors in
the calling code. Doing it based on the virtual type ignores latent bugs in
specific instances where they are harmless. I can't understand why that's a
good idea.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8025] New: std.net.curl.del should return response body.
http://d.puremagic.com/issues/show_bug.cgi?id=8025 Summary: std.net.curl.del should return response body. Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: repeate...@gmail.com --- Comment #0 from Masahiro Nakagawa repeate...@gmail.com 2012-05-03 12:07:29 PDT --- Currently, return type of del is void. void del(Conn = AutoProtocol)(const(char)[] url, Conn conn = Conn()) if (isCurlConn!Conn) But HTTP's DELETE sometimes returns response body(Sorry, I don't know FTP). In such cases, current del is not usable. Return type of del should be T[] same as other functions, e.g. get, put and etc... -- 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 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 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 #2 from github-bugzi...@puremagic.com 2012-05-03 13:27:36 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/704977f1decd9b2d589bd40431f5d001b0aa6d4e Add test cases for bug 8023 https://github.com/D-Programming-Language/dmd/commit/c947c201cd59ecb0db618acefe4a528a2d6ee1d5 Merge pull request #922 from llucax/test8023 Add test case for bug 8023 -- 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 --- Comment #8 from github-bugzi...@puremagic.com 2012-05-03 13:28:18 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fb797c20e97ccfe18e0ec483dc8373e8028991de Add test case for bug 8016 https://github.com/D-Programming-Language/dmd/commit/731fb84247f170d7de8ae091f90c61134e548c1e Merge pull request #921 from llucax/test8016 Add test case for bug 8016 -- 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 #17 from deadalnix deadal...@gmail.com 2012-05-03 13:44:36 PDT ---
(In reply to comment #15)
fizbuzzA(A a) {
a.foo(); // A.foo's in contract is valid
}
If an instance of B is passed to fizbuzzA, then the a.foo() will call B.foo(),
and either A.foo's in contract or B.foo's in contract must be valid.
There is no error or invalid corner case here.
I suspect that you think the contracts are checked based on static typing -
they are not, they are done using the virtual type.
We are all well aware that the behavior you describe is the current behavior.
However we do think it is not optimal and can be improved because of the corner
case mentioned.
As you can see in given code, fizbuzzA is an invalid piece of code waiting to
explode in your face. And this is what you want to avoid, why we use so much
stuff like contracts and unit tests (and, as far as I am concerned in my
professional work, code review and static analysis tools).
The later the bug is discovered, the more expansive it is to fix, and, if it
goes in production, the more damage it can do. We want to avoid as much as we
can the risk of having a piece of code waiting to explode deep in the codebase.
fizzbuzzA is the typical example of the function that will cost you quite a
lot. It is flawed, and waiting to crash the application at any moment. We want
to detect that ASAP, and in contract should tell us that ASAP.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8026] New: Fix or disallow randomShuffle() on fixed-sized arrays
http://d.puremagic.com/issues/show_bug.cgi?id=8026
Summary: Fix or disallow randomShuffle() on fixed-sized arrays
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-05-03 13:45:51 PDT ---
This comes after a report by Vidar Wahlberg:
http://forum.dlang.org/thread/jnu1an$rjr$1...@digitalmars.com
Several functions of std.algorithm don't work with fixed-sized arrays, and
require you to slice them first to turn them into ranges. But
std.random.randomShuffle() accepts fixed-sized arrays as well:
import std.stdio: writeln;
import std.random: randomShuffle;
void main() {
int[6] data = [1, 2, 3, 4, 5, 6];
randomShuffle(data);
writeln(data);
}
This prints the unshuffled array:
[1, 2, 3, 4, 5, 6]
This is bug-prone, and in my opinion it's not acceptable.
I see two alternative solutions:
1) To make randomShuffle() properly support fixed-sized arrays, taking them by
reference;
2) To make randomShuffle() refuse a fixed-sized array at compile-time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8026] Fix or disallow randomShuffle() on fixed-sized arrays
http://d.puremagic.com/issues/show_bug.cgi?id=8026 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com Severity|enhancement |normal --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-03 14:07:29 PDT --- Well, that's certainly weird. Range-based functions don't normally take static arrays, and I'd argue that they shouldn't, given the problems surrounding slicing static arrays (it's fine to do it, but you need to be aware of what you're doing) - though randomShuffle doesn't have the same problem as most range-based functions do with static arrays given that it's void. Still, I'd argue that it's probably better for it to require slicing like all the rest. It looks like the problem is that randomShuffle doesn't have a template constraint (obviously not good), so I very much doubt that it was ever intended to work with static arrays without slicing. uninformDistribution (which is right above randomShuffle) appears to have the same problem. I'd say that this is definitely a bug, not an enhancement. If I remember, I'll probably throw together a pull request for it tonight, since it should be a quick fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8027] New: in contract is never checked for overrided functions
http://d.puremagic.com/issues/show_bug.cgi?id=8027
Summary: in contract is never checked for overrided functions
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: adam.chrapkow...@gmail.com
--- Comment #0 from Adam Chrapkowski adam.chrapkow...@gmail.com 2012-05-03
14:11:30 PDT ---
import std.stdio;
class Foo {
int foobar(int a, int b)
in {
assert (a 0 b 0);
writeln(Foo in);
} out(ret) {
assert(ret 0);
writeln(Foo out);
} body {
return a + b;
}
}
class Bar : Foo {
override int foobar(int a, int b)
in {
assert(a * b + 8 1);
writeln(Bar in);
} out(ret) {
assert (ret 1);
writeln(Bar out);
} body {
return 2;
}
}
void main() {
try {
auto _foo = new Bar();
_foo.foobar(1, 2);
} catch (Exception e) {
writeln(e);
}
}
__
IN contract for function Bar.foobar() is never checked.
For me it makes sense (becuse in contracts must be checked by the caller which
may not know anything about overriding function) but compiler should not allow
to define IN contract for an overriding function.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8027] in contract is never checked for overrided functions
http://d.puremagic.com/issues/show_bug.cgi?id=8027 timon.g...@gmx.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||timon.g...@gmx.ch Resolution||DUPLICATE --- Comment #1 from timon.g...@gmx.ch 2012-05-03 14:32:27 PDT --- *** This issue has been marked as a duplicate of issue 6856 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6856] Preconditions are not inherited
http://d.puremagic.com/issues/show_bug.cgi?id=6856 timon.g...@gmx.ch changed: What|Removed |Added CC||adam.chrapkow...@gmail.com --- Comment #27 from timon.g...@gmx.ch 2012-05-03 14:32:27 PDT --- *** Issue 8027 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 8027] in contract is never checked for overrided functions
http://d.puremagic.com/issues/show_bug.cgi?id=8027 timon.g...@gmx.ch changed: What|Removed |Added Resolution|DUPLICATE |INVALID --- Comment #2 from timon.g...@gmx.ch 2012-05-03 14:35:25 PDT --- Oops, actually this is not a duplicate, it is just invalid. This is how precondition inheritance is supposed to work. (a0 b0 suffices as a condition for the inheriting class to need to accept the input, therefore the additional in-contract is not even checked.) -- 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 #18 from Walter Bright bugzi...@digitalmars.com 2012-05-03 15:37:00 PDT --- (In reply to comment #17) As you can see in given code, fizbuzzA is an invalid piece of code waiting to explode in your face. There is no bug in example #14. Please show one where it blows up. -- 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 #19 from Walter Bright bugzi...@digitalmars.com 2012-05-03 15:46:03 PDT --- (In reply to comment #16) This is the issue. WHY are they done based on the virtual type? Checking the contracts based on static typing would detect logical errors in the calling code. Doing it based on the virtual type ignores latent bugs in specific instances where they are harmless. I can't understand why that's a good idea. The whole idea of polymorphism is to base things on the virtual type. I don't understand what latent bugs you are referring to. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 5765] ^^ and with BigInts
Hi Whats the status on a BigInt implementation of modular exponentiation?
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 Stewart Gordon s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #20 from Stewart Gordon s...@iname.com 2012-05-03 16:45:21 PDT --- (In reply to comment #5) This is incorrect. It must satisfy the precondition for A or any class derived from A. The in contract is part of the API of class A. If you call a method of A with arguments that don't satisfy this contract, you are not conforming to the API. (In reply to comment #10) It isn't a bug, it is the way it is supposed to work. Nor am I ignoring it - I'm trying to explain it. You're explaining the design you're copying. That's quite different from explaining why you've chosen to copy this particular design to the letter. (In reply to comment #19) (In reply to comment #16) This is the issue. WHY are they done based on the virtual type? Checking the contracts based on static typing would detect logical errors in the calling code. Doing it based on the virtual type ignores latent bugs in specific instances where they are harmless. I can't understand why that's a good idea. The whole idea of polymorphism is to base things on the virtual type. What are things? If you mean the effect of a call, then yes. This we seem to be all agreed on. If you mean whether a given call is legal, then you could by the same argument insist that called method names must be resolved in the context of the virtual type. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8028] New: Templates sometimes-can/sometimes-can't access private symbols in same module
http://d.puremagic.com/issues/show_bug.cgi?id=8028
Summary: Templates sometimes-can/sometimes-can't access private
symbols in same module
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: cbkbbej...@mailinator.com
--- Comment #0 from Nick Sabalausky cbkbbej...@mailinator.com 2012-05-03
17:16:53 PDT ---
--
// test1.d
import test2;
auto a = foo!1;
--
// test2.d
template foo(int i)
{
immutable foo = makeStruct(i); // A
//immutable foo = MyStruct(i); // B
}
private MyStruct makeStruct(int i)
{
return MyStruct(i);
}
struct MyStruct
{
private this(int i) {}
}
--
In test2.d, using the line marked A compiles successfully, but using the line
marked B results in:
Error: struct test2.MyStruct member this is not accessible
I don't know whether they're supposed to both succeed or both fail, but that
fact that one works and the other doesn't sounds like a compiler bug to me.
--
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 Stewart Gordon s...@iname.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #21 from Stewart Gordon s...@iname.com 2012-05-03 17:20:19 PDT --- Let's look at it another way. The relevant basic principle of inheritance is the ability to extend the functionality of a class, i.e. add to what can be done with its objects. There are two main ways in which a class B can extend the functionality of a class A: (a) adding new methods (b) widening the range of legal inputs to an existing method In order for a class user to take advantage of (a), it must have a reference of type B. You can't call these new methods through a reference of type A. To be sound, (b) should be equally subject to this requirement. It might be Walter's decision that, in D, (b) is going to continue to be exempt from this requirement. But then it's a WONTFIX. But otherwise, it's reasonable that some people may want (b) to be subject to the requirement, while others may want it to be exempt from it. It's an open matter of debate, therefore whatever this issue is, it certainly isn't INVALID. -- 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 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #22 from Walter Bright bugzi...@digitalmars.com 2012-05-03 17:49:32 PDT --- Please stop reopening this. If you mean whether a given call is legal, then you could by the same argument insist that called method names must be resolved in the context of the virtual type. And they are. It's what the vtbl[] is for. (b) is going to continue to be exempt from this requirement. You cannot widen the requirements of a function without providing an override of it. A.foo() cannot be called with the widened requirements of B.foo() - B.foo() gets called. That's why it can be overridden. IT WORKS CORRECTLY. The virtualness of the contracts is directly connected to the virtualness of the function calls. As for the design decision on this, the decision was (and is) to implement classic OOP. It is theoretically sound. This is well trod and (I thought) well understood territory. As Andrei pointed out, it is not open for debate what OOP is. 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. If we try and implement alternate and incorrection notions of OOP, D will be considered a lightweight language run by amateurs. It is entirely possible that: 1. I have seriously misunderstood OOP (I have made more than my share of such mistakes before). 2. The OOP community has got it all wrong. 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. -- 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 #23 from Stewart Gordon s...@iname.com 2012-05-03 18:21:44 PDT ---
(In reply to comment #22)
If you mean whether a given call is legal, then you could by the
same argument insist that called method names must be resolved in
the context of the virtual type.
And they are. It's what the vtbl[] is for.
???
class A {}
class B : A {
void foo() {}
}
void main() {
A a = new B;
a.foo();
}
You're claiming that this code is legal, and the penultimate line resolves to
B's foo method???
(b) is going to continue to be exempt from this requirement.
You cannot widen the requirements of a function without providing
an override of it. A.foo() cannot be called with the widened
requirements of B.foo() - B.foo() gets called. That's why it can
be overridden.
The concept of overriding in OOP as I've been brought up to understand it
applies to what the method does, a quite different concept from what are legal
inputs to it.
As for the design decision on this, the decision was (and is) to
implement classic OOP. It is theoretically sound. This is well
trod and (I thought) well understood territory. As Andrei pointed
out, it is not open for debate what OOP is.
I'm surprised that the classic OOP spec covers the behaviour of contracts at
all. But maybe I just need to read up on it.
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.
At least I seem to have three potential co-authors already
--
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 #24 from Walter Bright bugzi...@digitalmars.com 2012-05-03
18:50:03 PDT ---
(In reply to comment #23)
(In reply to comment #22)
If you mean whether a given call is legal, then you could by the
same argument insist that called method names must be resolved in
the context of the virtual type.
And they are. It's what the vtbl[] is for.
???
class A {}
class B : A {
void foo() {}
}
void main() {
A a = new B;
a.foo();
}
You're claiming that this code is legal, and the penultimate line resolves to
B's foo method???
No, I'm not. This thread is about overriding, not introducing, functions.
I'm surprised that the classic OOP spec covers the behaviour of contracts at
all. But maybe I just need to read up on it.
Betrand Meyer's Object Oriented Programming. You can get it on amazon for
$5.99. It's the definitive classic on the topic.
The behavior with contracts is just another aspect of the contravariance and
covariance of derived objects.
--
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 #25 from Stewart Gordon s...@iname.com 2012-05-03 19:02:13 PDT --- (In reply to comment #24) No, I'm not. This thread is about overriding, not introducing, functions. It's about introducing new legal inputs to a function. Which is conceptually more like introducing a new function than overriding an existing function. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8026] Fix or disallow randomShuffle() on fixed-sized arrays
http://d.puremagic.com/issues/show_bug.cgi?id=8026 --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-03 19:55:52 PDT --- https://github.com/D-Programming-Language/phobos/pull/565 -- 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 --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2012-05-03 20:19:02 PDT --- The test cases were reverted because they failed in the auto-tester. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
