DIP 1003 Formal Review

[MysticZach via Digitalmars-d]

On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
> To me, it's actually worse, because now you have a visual 
> conflation with do-loops.
>
> Overall, what I don't like about contract syntax is that it is 
> so unbearably verbose. It's not just the in and out blocks and 
> the (IMO redundant) marking of the function body; it's also the 
> repeated 'assert's that occur in the in and out blocks.
>
> 	int foo(T, U)(T t, U u)
> 	if (sigContraints!T && sigConstraints!U)
> 	in
> 	{
> 		assert(t > 0 && u < 10);
> 	}
> 	out(val)
> 	{
> 		assert(val > 1 && val < 5);
> 	}
> 	body
> 	{
> 		// function body here
> 	}
>
> I understand this DIP is only to address the `body` part of 
> this ugly verbosity, but imagine how much better it would be if 
> we could write something like this instead:
>
> 	int foo(T, U)(T t, U u)
> 	if (sigConstraints!T && sigConstraints!U)
> 	in (t > 0 && u < 10)
> 	out(foo > 1 && foo < 5 )
> 	{
> 		// function body here
> 	}
>
> This is just tentative example syntax, of course.  We can argue 
> over its fine points later, but the point is that the current 
> syntax is far too verbose, and can easily be reduced to half 
> the number of lines.  Merely changing `body` to `do` does 
> nothing to address this, and seems to me to be just more 
> useless churn, replacing one bit of verbosity with another bit 
> of verbosity. (Not to mention the IMO very ugly syntax clash 
> with do-loops, which will reduce code readability even more.)
>
>
> T

I think there are several issues at hand, and they need to be 
dealt with individually:

1. `body` is a very useful identifier. It would be nice to have 
it available.

2. Contract syntax is too verbose.

3. a. Some people think code looks better with a keyword, e.g. 
`body`, `do`, etc. distinguishing the function from the contracts.

3. b. Other people think that such a keyword is unnecessarily 
redundant and does not justify its own existence.

I think the thread will be more productive if the posters commit 
to answering just one of these issues, and reserve other issues 
for other threads. As the DIP in question is directly meant to 
address issue #1, it makes sense to try to solve that problem and 
only that problem here.