<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Wed., 16 May 2018, 12:52 pm Jonathan M Davis via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, May 16, 2018 12:16:11 Manu via Digitalmars-d wrote:<br>
> So, in/out contracts are cool. They can be used to assert valid value<br>
> ranges for arguments and return values.<br>
> This is useful for proving correctness, and also, this limiting of<br>
> value ranges is information that the optimiser can take and use in<br>
> various optimisations.<br>
><br>
> I often call to extern C/C++ code, or even to D code built in a static<br>
> lib with a .di as interface.<br>
> Sadly, in/out contracts can not be used and offer no advantage in<br>
> these cases, because calls are  made via function prototypes.<br>
><br>
> I'm wondering if it should also be possible to apply in/out contracts<br>
> to function prototypes?<br>
> They are usually evaluated in the entry/exit blocks when compiling<br>
> functions, but when applied to prototypes, they would rather need to<br>
> be evaluated immediately before/after the function call in the calling<br>
> code.<br>
><br>
> Some advantages of this are:<br>
>   - Attributing C/C++ functions with contracts to prove that they're<br>
> called correctly, where calling from C code would otherwise just rely<br>
> on documentation to inform correct arguments.<br>
>   - The optimiser is able to gain value from known valid value ranges,<br>
> even when inlining is not possible (ie, opaque binary interface/libs).<br>
><br>
> This is kinda neat; we are able to offer a superior experience wrt<br>
> perf and correctness, even when calling C api's! (assuming the author<br>
> of the C binding takes the time to translate the documented argument<br>
> validity to contracts, which feels worth the effort!)<br>
<br>
Really, ideally, contracts would be treated as part of the signature and<br>
would be compiled in or not based on the caller and not the callee - e.g.<br>
you shouldn't have to use a debug build of Phobos to get the assertions in<br>
its in and out contracts when you call any of its non-templated functions.<br>
Those assertions are testing the caller, not the function that they're<br>
associated with. As such, they really should be compiled in on the caller<br>
side regardless of any performance considerations. As it is, outside of<br>
classes, contracts don't really buy you anything over simply putting<br>
assertions in the function body.<br>
<br>
Unfortunately, I have no idea how easy it would be to move the contracts to<br>
the caller side, and there's the question of how that works with separate<br>
compilation (since presumably at that point, the contracts would be treated<br>
as part of the signature and need to be with the signature, which is not the<br>
case at all right now). But if we could make a change like that, it would<br>
actually make contracts worth something IMHO, whereas right now, I think<br>
that they're mostly pointless, because you can get the same effect with<br>
assertions in the function itself.<br>
<br>
This issue pops up every so often, and I expect that it will continue to do<br>
so until we solve it or determine that it's not reasonably feasible, but<br>
someone with the appropriate expertise about the implementation issues is<br>
going to need to write a DIP about it, or all we're likely to do is to talk<br>
about how nice it would be if it happened.<br>
<br>
- Jonathan M Davis<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is exactly the type of issue where the new dip system is really impotent, and a disadvantage compared to the prior process.</div><div dir="auto"><br></div><div dir="auto">For something like this where it would be nice but it doesn't block anyone, nobody will ever take the time to write a dip.</div><div dir="auto">It should just be fixed by someone who knows how to do it. I'm sure it's not even slightly controversial.</div><div dir="auto"><br></div><div dir="auto">I miss Kenji!</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>