[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #56 from Don clugd...@yahoo.com.au 2012-05-06 00:36:04 PDT ---
(In reply to comment #55)
Mea culpa.
I read Meyer's book again. Chapter 16.1 Cutting out the middleman pg. 575
says:
A client of MATRIX must satisfy the original (stronger) precondition, and may
only expect the original (weaker) postcondition; even if its request gets
served dynamically by NEW_MATRIX it has no way of benefiting from the broader
tolerance of inputs and tighter precision of results. To get this improved
specification it must declare the matric to be of type NEW_MATRIX, thereby
losing access to other implementations represented by descendants of MATRIX
that are not also descendants of NEW_MATRIX.
(MATRIX is the base class, NEW_MATRIX is the derived class.)
So I'm reopening it as a normal bug.
Unfortunately, I do not currently see a reasonable way of implementing this.
Fortunately, as is it does not inhibit correct programs, it only accepts some
invalid ones.
I think implementation is simpler than what happens at present. You need a
static function thunk for each virtual function with a precondition.
For example:
class A {
int foo(int n) in { assert(n 0); } body { return n; }
}
class B {
int foo(int n) { return n+1; } // no change to precondition
}
class C {
int foo(int n) in { assert(n -10 n-6); } body { return n+2; }
becomes (I've put 'virtual' in to make things clearer):
class A {
static void foo_in(A x) { assert(n0); }
virtual int foo(int n) { foo_in(this, n); return foo_body(n); }
virtual int foo_body(int n) { return n; }
}
class B {
virtual int foo_body(int n) { return n+1; }
}
class C {
static void foo_in(C x, int n) { assert(n -10 n-6); }
virtual int foo(int n ) {
if (C.foo_in(this, n)) return foo_body(n); // passed C's precondition
return A.foo(n); // failed, try A's precondition
}
virtual int foo_body(int n) { return n+2; }
}
--
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 #57 from deadalnix deadal...@gmail.com 2012-05-06 02:20:47 PDT --- (In reply to comment #55) So I'm reopening it as a normal bug. Thank you ! Unfortunately, I do not currently see a reasonable way of implementing this. Fortunately, as is it does not inhibit correct programs, it only accepts some invalid ones. That is not this complicated. you need a final function that check the in contract, then call another virtual function that actually execute the function body and the out contract. With such a configuration, the in contract is checked and only then the virtual dispatch is done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 6857] Precondition contract checks should be statically bound.
On 5/6/2012 2:19 AM, d-bugm...@puremagic.com wrote: That is not this complicated. you need a final function that check the in contract, then call another virtual function that actually execute the function body and the out contract. With such a configuration, the in contract is checked and only then the virtual dispatch is done. It's not that simple. Several considerations have to be met: 1. Because of struct construction/destruction, you really only want to construct the parameter list *once*, but you're calling two functions with the same parameter list. 2. Variadic functions mean that one function cannot forward to another one using standard functions. (Perhaps a dirty magic thunk can work.) 3. The presence or absence of contracts must not change the ABI of the function. 4. The virtual table must be unchanged. 5. It's not so practical to jump into the middle of another function - things just aren't designed that way. 6. The caller now has to be aware of contracts in the called function, this was never necessary before.
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #59 from deadalnix deadal...@gmail.com 2012-05-06 03:27:45 PDT --- (In reply to comment #58) It's not that simple. Several considerations have to be met: 1. Because of struct construction/destruction, you really only want to construct the parameter list *once*, but you're calling two functions with the same parameter list. Arguments should really be const in contracts. And if they are not modified (and considering that argument are the same for in contract function and real function) it is probably doable to jump right into the implementation function just after the prolog. 2. Variadic functions mean that one function cannot forward to another one using standard functions. (Perhaps a dirty magic thunk can work.) Again, I think jumping right into the function can do the trick. 3. The presence or absence of contracts must not change the ABI of the function. That one seem really difficult. An alternative would be to do 2 function calls, one for in contract and one for the function body. Another option is to consider contract as being part of the declaration and so cannot be opaque. 4. The virtual table must be unchanged. With proposed solution it will, even if a direct call throw the virtual table would skip the in contract. 5. It's not so practical to jump into the middle of another function - things just aren't designed that way. Already did that. This isn't something you want to do every day, but it doable. 6. The caller now has to be aware of contracts in the called function, this was never necessary before. Indeed, the caller now has to be aware of the existence of in contracts. This is required if you want to check contract according to caller's type and not real type. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8052] New: Spurious warning when exiting out of a labeled Do-While
http://d.puremagic.com/issues/show_bug.cgi?id=8052
Summary: Spurious warning when exiting out of a labeled
Do-While
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kekeni...@yahoo.co.jp
--- Comment #0 from kekeni...@yahoo.co.jp 2012-05-06 04:06:47 PDT ---
Building the following code, I get an incorrect warning.
int test()
{
loop:
do {
break loop;
} while(false);
return 0; // isn't unreachable.
}
---
Warning: statement is not reachable
D1 does not warn.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8044] Print names, not casted values when using enum template parameter
http://d.puremagic.com/issues/show_bug.cgi?id=8044 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2012-05-06 06:50:44 PDT --- See also Issue 5004 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5004] show both resolved symbols and original identifier in error messages involving aliases
http://d.puremagic.com/issues/show_bug.cgi?id=5004
--- Comment #9 from bearophile_h...@eml.cc 2012-05-06 06:52:35 PDT ---
One case:
alias ushort UT;
void main() {
int x;
UT y = x;
}
DMD 2.060alpha gives:
test.d(4): Error: cannot implicitly convert expression (x) of type int to
ushort
But a more useful error message is similar to:
test.d(4): Error: cannot implicitly convert expression (x) of type int to UT
(alias for ushort)
See also Issue 8044
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8055] New: std.algorithm.move corrupts moved object field
http://d.puremagic.com/issues/show_bug.cgi?id=8055
Summary: std.algorithm.move corrupts moved object field
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-05-06 19:16:22 PDT ---
import std.algorithm;
struct S
{
int x;
~this()
{
assert(x == 0); // Line7
}
}
S foo(S s)
{
return move(s);
}
void main()
{
S a;
a.x = 0;
auto b = foo(a);
assert(b.x == 0);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8055] [Regression 2.059] std.algorithm.move corrupts moved object field
http://d.puremagic.com/issues/show_bug.cgi?id=8055
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Summary|std.algorithm.move corrupts |[Regression 2.059]
|moved object field |std.algorithm.move corrupts
||moved object field
Severity|normal |regression
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-05-06 19:27:29 PDT ---
Sorry, I accidentally posted that is only half written.
(In reply to comment #0)
import std.algorithm;
struct S
{
int x;
~this()
{
assert(x == 0); // Line7
}
}
S foo(S s)
{
return move(s);
}
void main()
{
S a;
a.x = 0;
auto b = foo(a);
assert(b.x == 0);
}
output:
core.exception.AssertError@test(7): Assertion failure
This regression is introduced this commit:
https://github.com/D-Programming-Language/phobos/commit/71b1c1a
In unary move(), result is uninitialized. If T has an elaborate destructor, it
is called on corrupted memory.
--
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 #60 from Andrei Alexandrescu and...@metalanguage.com 2012-05-06 19:48:55 PDT --- This has been some significant pwning of Walter and myself, and I think there is a larger lesson here we should learn. We essentially operated from vague memories instead of actually going back and revisit the sources. This must be how some dogma is born - an imprecise and incorrect recollection of some assumption that becomes petrified. What I think we should do going forward is to make sure we state and document our assumptions instead of relying on rote recollection. The DbC-related documentation and language specification should contain chapter and page of Meyer's work. There's a good reason why all academic work makes sure cites all of its sources, and even that is liable to mistakes of the kind we've done. Thanks to all who have pursued this matter. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8056] New: Properties should behave like variables, e.g. compound assignments
http://d.puremagic.com/issues/show_bug.cgi?id=8056
Summary: Properties should behave like variables, e.g. compound
assignments
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: wfunct...@hotmail.com
--- Comment #0 from wfunct...@hotmail.com 2012-05-06 20:19:48 PDT ---
This should compile if properties are to be used as variables:
@property int foo() { return 1; }
@property void foo(int v) { }
void main()
{
foo |= 2;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8057] New: std.algorithm.move cannot use for nested struct
http://d.puremagic.com/issues/show_bug.cgi?id=8057
Summary: std.algorithm.move cannot use for nested struct
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-05-06 20:31:19 PDT ---
import std.algorithm;
void main()
{
int n = 10;
struct S
{
int x;
~this()
{
// Access to enclosing scope
assert(n == 10);// Line11
}
}
S foo(S s)
{
// Move nested struct
return move(s);
}
S a;
a.x = 1;
auto b = foo(a);
import core.stdc.stdio;
printf(a.x = %d\n, a.x);
assert(b.x == 1);
}
output:
core.exception.AssertError@test(11): Assertion failure
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8056] Properties should behave like variables, e.g. compound assignments
http://d.puremagic.com/issues/show_bug.cgi?id=8056 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-06 20:32:51 PDT --- A related issue would be incrementing and decrementing properties. e.g. ++foo; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8055] [Regression 2.059] std.algorithm.move corrupts moved object field
http://d.puremagic.com/issues/show_bug.cgi?id=8055 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-05-06 20:38:49 PDT --- https://github.com/D-Programming-Language/phobos/pull/572 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8057] std.algorithm.move cannot use for nested struct
http://d.puremagic.com/issues/show_bug.cgi?id=8057 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-05-06 20:39:21 PDT --- https://github.com/D-Programming-Language/phobos/pull/572 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
