On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
Not that a whole new way of doing things is called for... but
I think a better design would have been to allow 'in' and
'out' statements in the function itself, with no need for
brackets if you only have one line's worth of contract, e.g.,
int fun(int a) {
in assert(...);
out(x) assert(...);
// do stuff
}
It's nice, i like it but it cant work as simply. You're
forgetting that interface member functions can have contracts.
With this syntax interfaces member functions would always have
a body BUT the current semantic is that interface member
functions with bodies are final methods. Boom. Interfaces don't
work anymore because there's no easy way to make the difference
between an interface member function that's final and an
interface member function that's not pre-implemented (so
overridable) but has contracts.
It seems to me that the compiler could detect a presence or lack
of a body simply by the presence or absence of any statement
after the contracts, i.e.,
interface D {
// fun is implicitly overridable here
int fun() {
in assert(...);
}
}
Also, does a final function with contracts, but no body, make any
sense? What's the use case?
Even if there were some use case for it, I can think of two
solutions. One is to keep and require the current syntax for an
interface function without a body. This is the natural way to
install contracts anyway, for a function with no body.
The other solution is to recommend the addition of an empty
statement, for an empty final function, e.g.:
// final
int fun() {
in assert(...);
{}
}
Considering what Jonathan said about how he never uses contracts
because they're so bulky, might it not be worth it to solve the
interface problem in either of the above two ways?
