new contract syntax DIP

[MysticZach via Digitalmars-d]

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.)