On Thursday, 5 February 2015 at 05:42:59 UTC, Meta wrote:
On Thursday, 5 February 2015 at 01:33:54 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 5:32 PM, deadalnix wrote:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei
Alexandrescu wrote:
Yah, I agree "in" is useful for overridable functions. In
fact I'd say
it's useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for
overridable
functions.
1/ If a lib is compiled in without contract, but your code is
compiled
with, you get the in contract to run when you call library
code, but not
the assert within the function.
2/ The optimizer see the properties of the argument when they
get to the
in contract. This information is lost in the callee, unless
inlining
goes on. that means the amount of contract the optimizer can
remove
statically is greater with in contract.
Yah, I understand the potential there. Consider me grudgingly
convinced :o). -- Andrei
I don't know about others (besides Beatophile, who religiously
adheres to writing contacts), but putting contracts on
functions is a hassle. I never do it unless I'm feeling
particularly full of divine fervor. It's a lot like making all
variables that don't need to be changed immutable (another
thing which only Bearophile seems to do) or properly
documenting code. Strong optimization guarantees from contracts
would go a long way in convincing people to actually write them
(although I guess that's not what you want; Perhaps you changed
your mind). It's a chicken and egg problem.
I also make all my variables immutable unless I can't. Which is
annoyingly and surprisingly often. Sometimes I have to downgrade
to const (usually because of strings), sometimes I have to rather
sadly go back to auto. I never like it when I do. I should
probably do more contract programming.
immutable is good. immutable is your friend. AFAIC, mutable state
is the root of all evil.
Atila
