| |
 | Posted by MysticZach
in reply to arturg |  Permalink Reply |
|
MysticZach 
Posted in reply to arturg
| On Tuesday, 23 May 2017 at 19:04:46 UTC, arturg wrote:
> how about @uda based contracts?
>
> @in(x => x < 100)
> @out((ret) { assert(ret > 0, "some text"); })
> int fun(int i) { return someVal; }
>
> they could also be used on type definitions,
>
> @out((t) { assert(t); })
> class NotNull {}
>
> or temporarly on instances
>
> @in(t => t !is null) auto notNull = new NotNull;
>
> you could also have @inout as a combination.
> another feature would be that they could be introspected.
Well I was going for three things:
1. contracts simple to write, with minimal "extra plumbing", i.e. without brackets and parentheses
2. utilize existing contract infrastructure
3. minimal divergence from existing syntax and semantics.
While not having to write `assert` in contracts would save a little space, it reduces what you can do with them, and also introduces a whole new semantics. The @uda contract system you suggest would require extensive description, documentation, and probably implementation effort. It would have to demonstrate that there was no better way to solve the problems it solves. (I'm not even sure I can justify my little syntax change, let alone a whole new semantics. I don't even know if contracts in general are important enough to be worth improving their syntax.)
So yeah, one could do things differently. But just because you _can_ do things differently doesn't mean you should. And justifying _why_ you should is not easy. And if people are being reasonable, they should maintain very high standards for what goes into a general-purpose programming language. Because there are a lot of things you can't take back once they're in there. (On the other hand, you don't want to stagnate, and not change _anything_, just for fear of making a mistake. One should strive for a balance.)
|
