[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #8 from github-bugzi...@puremagic.com 2012-05-04 23:00:44 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/2a5385345c17a65f8280efab1674c23bde3df68e fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6199] [GSoC] Postblit not called when returning a reference to a by-value function.
http://d.puremagic.com/issues/show_bug.cgi?id=6199 --- Comment #2 from SomeDude lovelyd...@mailmetrash.com 2012-05-04 23:01:01 PDT --- See also related issue 5737 and issue 8045 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #9 from github-bugzi...@puremagic.com 2012-05-04 23:01:16 PDT --- Commit pushed to phobos-1.x at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/df21e384a4207e6f888b5abed0f7b3298a2d0320 fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #10 from github-bugzi...@puremagic.com 2012-05-04 23:02:33 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/39c0a6ec5e2d1ae412d5d60834feb8ab610b090e fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 Walter Bright bugzi...@digitalmars.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 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #11 from github-bugzi...@puremagic.com 2012-05-04 23:02:48 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ca53f96c09be934c51b2ea1d91c277639181cfec fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8045] Postblit should be called on function call initilalizer that returns ref
http://d.puremagic.com/issues/show_bug.cgi?id=8045 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:30:37 PDT --- (In reply to comment #1) Isn't this a duplicate of issue 5737 and issue 6199 ? There are currently 12 open bugs concerning postblit. I suspect some are duplicates, but I'm not sure which. http://d.puremagic.com/issues/buglist.cgi?query_format=advancedchfield=resolutionshort_desc=Postblitchfieldvalue=FIXEDbug_severity=regressionbug_severity=blockerbug_severity=criticalbug_severity=majorbug_severity=normalbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDversion=D2short_desc_type=allwordssubstrcomponent=DMDcomponent=druntimecomponent=Phobosresolution=---product=D Thanks. You are right. I'll mark this as a dup of issue 5737. *** This issue has been marked as a duplicate of issue 5737 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5737] postblit not called for locals initialized from ref functions
http://d.puremagic.com/issues/show_bug.cgi?id=5737 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:30:37 PDT --- *** Issue 8045 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 5737] postblit not called for locals initialized from ref functions
http://d.puremagic.com/issues/show_bug.cgi?id=5737 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code Platform|Other |All OS/Version|Linux |All --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:31:21 PDT --- https://github.com/D-Programming-Language/dmd/pull/927 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6199] [GSoC] Postblit not called when returning a reference to a by-value function.
http://d.puremagic.com/issues/show_bug.cgi?id=6199 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code OS/Version|Windows |All --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:32:00 PDT --- https://github.com/D-Programming-Language/dmd/pull/927 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8046] New: simd.d needs some documentation
http://d.puremagic.com/issues/show_bug.cgi?id=8046 Summary: simd.d needs some documentation Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: worksonmymach...@gmail.com --- Comment #0 from Sean Cavanaugh worksonmymach...@gmail.com 2012-05-05 00:16:11 PDT --- Several of the enums in core/simd.d are not named after real opcodes so translating documentation from the intel processor manual is a bit confusing. For example: LODSS and STOSS are really forms of MOVSS. Are the arguments switched for either of these vs the MOVSS? This needs to be noted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8047] New: important opcodes missing from core/simd.d
http://d.puremagic.com/issues/show_bug.cgi?id=8047 Summary: important opcodes missing from core/simd.d Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: worksonmymach...@gmail.com --- Comment #0 from Sean Cavanaugh worksonmymach...@gmail.com 2012-05-05 00:31:58 PDT --- There are a number of opcodes that are missing, but some are far more critical than others, more or less listed here in order of most important first: missing store instructions (and some loads) STOSS STOSD STOAPS STOAPD STOD STOQ (there are a few others scattered in the enum table) movemask (critical for doing branching tests against simd registers): MOVMSKPD MOVMSKPS missing comparisons CMPPS CMPPD CMPSD CMPSS missing conversions CVTPS2PI CVTSD2SI CVTSI2SD CVTSI2SS CVTSS2SI CVTTPD2PI CVTTPS2PI CVTTSD2SI CVTTSS2SI -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords|patch | --- Comment #10 from Kenji Hara k.hara...@gmail.com 2012-05-05 00:42:06 PDT --- Pull #375 was not sufficient, so removed 'patch' keyword. -- 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 Saturday, 5 May 2012 at 05:57:31 UTC, Don wrote:
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.
Why would one expect the same behavior after changing the struct
to a class? The call to foo in the case of struct is statically
bound. f.foo *cannot* be bound to any other function than the one
declared in F, so it is *always* safe for compiler/theorem prover
to statically check the precondition.
Classes are a different story because of dynamic binding. There
will be cases where compiler/theorem prover will be able to
determine the static type at compile time and detect the error
early. Otherwise, it is obvious that the precondition must be
checked on the dynamic type at run-time.
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #47 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:02:48 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. --- Comment #48 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:03:05 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. -- 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 #47 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:02:48 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. --- Comment #48 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:03:05 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. -- 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.
Please reply on bugzilla, replying here is most likely to be overlooked.
[Issue 2389] void* vs. object type overloading fails for null giving bad error message
http://d.puremagic.com/issues/show_bug.cgi?id=2389 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:27:38 PDT --- Now produces: foo.d(10): Error: function foo.C.opIndexAssign called with argument types: ((typeof(null),int)) matches both: foo.C.opIndexAssign(void* _param_0, int _param_1) and: foo.C.opIndexAssign(C _param_0, int _param_1) -- 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 #49 from Stewart Gordon s...@iname.com 2012-05-05 04:40:48 PDT --- (In reply to comment #47) (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. You have completely ignored the whole point of this request, which has been explained to you by four of us several times over. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. Runtime polymorphism is about overriding behaviour, not overriding legality. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). What are you talking about? -- 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 #50 from deadalnix deadal...@gmail.com 2012-05-05 05:04:07 PDT ---
(In reply to comment #33)
(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.
This piece of code is good for an horror museum.
If bar is a valid argument for foo, then A should have the following definition
:
class A {
void foo(int x) in { assert(x 0); } body {}
int bar() out(result) { assert( result 0); } body { return 1; }
}
And, with such a definition, out contract would prevent B.bar to return -1 .
BTW, I found this PDF on Meyer's website :
se.ethz.ch/~meyer/publications/computer/contract.pdf . It seems that he decided
to publish the part of the book that is relevant to us online. I'm reading it
right 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 #51 from deadalnix deadal...@gmail.com 2012-05-05 06:22:21 PDT --- (In reply to comment #49) Runtime polymorphism is about overriding behaviour, not overriding legality. This is, indeed, the whole essence of the problem. (In reply to comment #48) And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I'm afraid this explains why we are not getting anywhere in this discussion. The whole proposal is, and have always been that one. Read again example code I've posted and which check is performed in which case. I have read Mayer's document about contract and OOP, and I want to comment here the explanations given by Meyer himself. Quoted passage are from the book. Mayer have a very similar example to the one I gave above. You have classes A and B inheriting from A. A define a method r with an in contract, that B override. A variable u of type A is used in method X. You can map as this : r = foo, u = a and X = fizzbuzzA « To ascertain the properties of the call u.r, the author of X can only look at the contract for r in A. Yet, because of dynamic binding, A may subcontract the execution of r to B, and it is B’s contract that will be applied. » Here, Meyer is stating HOW thing work before it explain WHY. Hence, the whole stuff is to show how this specific implementation satisfy certain properties. Let see what are these properties and what is the situation with the new proposed behavior. « How do you avoid “fooling” X in the process? There are two ways B could violate its prime contractor’s promises: - B could make the precondition stronger, raising the risk that some calls that are correct from x’s viewpoint (they satisfy the original client obligations) will not be handled properly. » I omitted the second one as it is about out contract so off topic here. the constraint expressed here is respected by both current solution, and proposed solution. « None of this, then, is permitted. But the reverse changes are of course legitimate. A redeclaration may weaken the original’s precondition or it may strengthen the postcondition. » Again, both proposals allow this. « Redeclaration. for all the power it brings to software development. is not a way to turn a routine into something completely different. The new version must remain compatible with the original specification. although it may improve on it. The noted rules express this precisely. » Meyer is right. His rules express this. But proposed rules express this too. He then conclude « In this way. the new precondition is guaranteed to be weaker than or equal to the originals, and the new postcondition is guaranteed to be stronger than or equal to the originals. » Again according to Meyer's argumentation, both behavior are corrects. It appears (and I have read the chapter several times to make sure I'm not missing something) that Meyer's doesn't provide any argument about our special case here. I'm sorry, but this reading can't close the discussion. -- 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 #52 from Andrei Alexandrescu and...@metalanguage.com 2012-05-05 08:54:17 PDT --- (In reply to comment #51) I'm sorry, but this reading can't close the discussion. I think it does. The proposed behavior does not allow this: None of this, then, is permitted. But the reverse changes are of course legitimate. A redeclaration may weaken the original’s precondition or it may strengthen the postcondition. Changes of either kind mean that the subcon- tractor does a better job than the original contractor-which there is no reason to prohibit. Doing a better job is succeeding where the parent method would have failed its precondition. It all boils down to the fact that it's natural to have methods that can't work in the parent but do work in the child. -- 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 #53 from deadalnix deadal...@gmail.com 2012-05-05 08:58:21 PDT ---
(In reply to comment #52)
(In reply to comment #51)
I'm sorry, but this reading can't close the discussion.
I think it does. The proposed behavior does not allow this:
None of this, then, is permitted. But the reverse changes are of course
legitimate. A redeclaration may weaken the original’s precondition or it may
strengthen the postcondition. Changes of either kind mean that the subcon-
tractor does a better job than the original contractor-which there is no
reason
to prohibit.
And indeed, it is not prohibited.
Doing a better job is succeeding where the parent method would have failed its
precondition. It all boils down to the fact that it's natural to have methods
that can't work in the parent but do work in the child.
It is stated (quoting myself) that :
« fizzbuzzB(B b) {
b.foo(); // (A.foo OR B.foo)'s in contract is valid
} »
Which exactly the behavior you talk about.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8048] New: Missing head function in std.net.curl
http://d.puremagic.com/issues/show_bug.cgi?id=8048 Summary: Missing head function in std.net.curl Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: repeate...@gmail.com --- Comment #0 from Masahiro Nakagawa repeate...@gmail.com 2012-05-05 09:24:06 PDT --- std.net.curl provides get, post, del, options, trace and connect functions corresponding to HTTP method. Why does not provide head function? I want head function to create a network library. -- 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 #54 from Stewart Gordon s...@iname.com 2012-05-05 09:21:02 PDT --- (In reply to comment #52) Doing a better job is succeeding where the parent method would have failed its precondition. It all boils down to the fact that it's natural to have methods that can't work in the parent but do work in the child. And to take advantage of this, one would deal with the child directly. -- 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 --- Comment #2 from github-bugzi...@puremagic.com 2012-05-05 13:37:02 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/785e7d608035d79ba5eafc812ae102e18d5fd53d fix Issue 8036 - Zero-length static array of structs with elaborate destructor as struct or class field is rejected https://github.com/D-Programming-Language/dmd/commit/9f807fb3c119f6ddeebd141c7b7eda53253a4716 Merge pull request #926 from 9rnsr/fix8036 Issue 8036 - Zero-length static array of structs with elaborate destructor as struct or class field is rejected -- 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 --- Comment #2 from Jacob Carlborg d...@me.com 2012-05-05 14:04:01 PDT --- Pull request: https://github.com/D-Programming-Language/druntime/pull/205 -- 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|RESOLVED|REOPENED Resolution|INVALID | Severity|enhancement |normal --- Comment #55 from Walter Bright bugzi...@digitalmars.com 2012-05-05 17:27:24 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8051] New: alias member not accessible
http://d.puremagic.com/issues/show_bug.cgi?id=8051
Summary: alias member not accessible
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-05-05
18:48:23 PDT ---
but it should be. dmd 2.059.
the code:
struct s{
union A{
int i;
}
A a;
alias a.i i;
}
template FIELD_OFFSET(T, string field){
enum FIELD_OFFSET = cast(size_t) mixin((cast(T*)null). ~ field);
}
void main(){
pragma(msg, FIELD_OFFSET!(s,i));
}
the fireworks:
test.d(9): Error: struct test.s 'i' is not a member
test.d(9): Error: struct test.s member i is not accessible
test.d(9): Error: this for i needs to be type A not type s
test.d(12): Error: template instance test.FIELD_OFFSET!(s,i) error
instantiating
cast(ulong)(__error).i
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
