[Issue 6857] Precondition contract checks should be statically bound.

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun May 6 03:26:30 PDT 2012


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



--- Comment #59 from deadalnix <deadalnix at 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: -------


More information about the Digitalmars-d-bugs mailing list