http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #80 from yebblies <yebblies@gmail.com> 2012-07-10 14:02:54 EST ---
(In reply to comment #79)
> (In reply to comment #78)
> But it does seem to be down to two problems with D's design:
> - structs aren't guaranteed to be safe to just bit-copy (this problem was
> introduced in D2)
> - we have variadics that are really just C's variadics with typeinfo added
> 

We also have C's variadics.

> Something else I should've realised earlier: Why do D class methods need to be directly callable from C?  (How does C code hold a reference to a D object, anyway?)  Indeed, is even C++ designed to accommodate this?

COM classes defined in D are callable from C (and you could define other
classes the same way).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #81 from Stewart Gordon <smjg@iname.com> 2012-07-10 05:05:48 PDT ---
(In reply to comment #80)
> (In reply to comment #79)
>> - we have variadics that are really just C's variadics with typeinfo added
> 
> We also have C's variadics.

But no use case I can see for using a C-style variadic for a D class method.

>> Something else I should've realised earlier: Why do D class methods need to be directly callable from C?  (How does C code hold a reference to a D object, anyway?)  Indeed, is even C++ designed to accommodate this?
> 
> COM classes defined in D are callable from C (and you could define other classes the same way).

But do any COM interfaces define C-style variadic methods?  Do we need to be open to this possibility, or are we wasting our time by worrying about it?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #82 from yebblies <yebblies@gmail.com> 2012-07-10 22:50:07 EST ---
(In reply to comment #81)
> (In reply to comment #80)
> > (In reply to comment #79)
> >> - we have variadics that are really just C's variadics with typeinfo added
> > 
> > We also have C's variadics.
> 
> But no use case I can see for using a C-style variadic for a D class method.
> 

I dunno, maybe you want to pass the args on to vprintf or something...  Does it really matter?

> >> Something else I should've realised earlier: Why do D class methods need to be directly callable from C?  (How does C code hold a reference to a D object, anyway?)  Indeed, is even C++ designed to accommodate this?
> > 
> > COM classes defined in D are callable from C (and you could define other classes the same way).
> 
> But do any COM interfaces define C-style variadic methods?  Do we need to be open to this possibility, or are we wasting our time by worrying about it?

COM does not use the C calling convention.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #83 from Stewart Gordon <smjg@iname.com> 2012-07-10 15:47:32 PDT ---
(In reply to comment #82)
> (In reply to comment #81)
>> But no use case I can see for using a C-style variadic for a D class method.
> 
> I dunno, maybe you want to pass the args on to vprintf or something...  Does it really matter?

I'd got the impression that D-style variadics are directly compatible in that respect.  But if D-style variadics were something more structured, I can see that passing them to a C variadic function would be trivial.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #84 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-09-05 07:24:44 PDT ---
Created an attachment (id=1143)
Inherited contracts

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #85 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-09-05 07:26:07 PDT ---
I've had the opportunity to discuss the matter with Bertrand Meyer himself and with a graduate student of his. Bertrand didn't have a defined answer offhand, but opined that the static contract should be evaluated. His book says the same .

Julian Tschannen (who allowed me to share his name here) wrote me the
following:

=========
1. Eiffel ECMA standard ([1], Rule 8.23.26) says, that the contract of
the dynamic type is checked, i.e. "pre_A OR ELSE pre_B"
(combined precondition, [1], Rule 8.10.5).

2. The Eiffel runtime does actually that, first checks the precondition of the parent class A, and then the precondition of the subclass B.

My take on the issue:
Dynamically it runs of course without a problem. If you would have a
static checker (e.g. the AutoProof tool that I am developing), the
code would be rejected due to the static check. Since we strive to get
a language that is statically checked and fully verified, it would
probably make more sense to just check the precondition of the static
type and not take the dynamic type into account for precondition
checks, since the client code works just with the given example and is
not correct for all possible arguments.
Or to be more precise, you could take all the static information into
account, but only the static information. It would for example be
possible that the client code has some precondition that would make
sure that the code is statically correct, even if the call - when
looked at in isolation - is statically not correct.
=========

So we currently do what the Eiffel standard and compiler do, but not what would probably be the most sensible thing. In my opinion we should do the right thing and check the contract statically.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #86 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-09-05 07:27:40 PDT ---
Forgot to mention - I attached the relevant page from the book (Walter found it) that makes it as clear as it gets how inherited preconditions should behave.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #87 from deadalnix <deadalnix@gmail.com> 2013-01-10 00:41:57 PST ---
(In reply to comment #85)
> I've had the opportunity to discuss the matter with Bertrand Meyer himself and with a graduate student of his. Bertrand didn't have a defined answer offhand, but opined that the static contract should be evaluated. His book says the same .
> 

You are lucky. I wrote him about that and he never answered me :'( .

> So we currently do what the Eiffel standard and compiler do, but not what would probably be the most sensible thing. In my opinion we should do the right thing and check the contract statically.

I think that this is the sane thing to do. However, this is tricky implementationwise.

Maybe we should update this bug report's tag according to what you announced here : http://forum.dlang.org/thread/kcijgh$25h6$1@digitalmars.com

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #88 from Andrei Alexandrescu <andrei@erdani.com> 2013-01-10 09:14:02 PST ---
@Walter: would you preapprove this?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------