On Thursday, 2 November 2017 at 20:37:11 UTC, user1234 wrote:
>     switch (i)
>         default: break;
> }
>
> you have 3 non-ambiguous and contiguous statements without a block: a switch, a default case (the "free-floating" one) and a break. Now why is this allowed is another story ;)

I've found a use for it - breakable blocks. (It's a bit neater than putting the label inside the block):

switch (1) default:
{
	auto x = foo();
	if (x == bar) break;
	auto y = x.baz();
	if (!y) break;
	y.writeln;
}

This avoids indentation from nested if statements instead of breaks. Although this is not ideal syntax, it's better than abusing a loop construct for something that's not a loop. Using a goto makes the code read less naturally as the label is after the block.

On 06.11.2017 03:32, Jonathan M Davis wrote:
> 
> I'm sure that there are various things that could be done to improve
> contracts (and DIP 1009 is one such attempt), but I've mostly given up on
> it. I don't think that they provide enough value in the first place. Aside
> from issues involving contracts and inheritance, in contracts can just be
> put in the function body,

The point of the in contract is to establish that it is the caller, and not the library author, who is responsible for ensuring it is satisfied.
It is slightly more obvious why this is crucial if your language has tooling for verifying assertions.

> making them kind of pointless, and for the most
> part, unit tests test anything that I would consider testing in an out
> contract

Then you are doing it wrong.

> - and generally do it better.

Unit tests alone do not test your code better than both unit tests and contracts.

On 11/1/17 11:11 PM, Meta wrote:
> On Wednesday, 1 November 2017 at 22:04:10 UTC, Andrei Alexandrescu wrote:
>> We're having difficulty reviewing https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md. The value is there, but the informal and sometimes flowery prose affects the document negatively. There are some unsupported claims and detailed description is sketchy. We need a careful pass that replaces the unclear or imprecise statements with clear, straightforward scientific claims.
>>
>> Can anyone help with this? For example, the first paragraph:
>>
>> "D has already made a significant commitment to the theory of Contract Programming, by means of its existing in, out, and invariant constructs. But limitations remain to their usability, both in their syntax and in their implementation. This DIP addresses only the syntax aspect of those limitations, proposing a syntax which makes in, out, and invariant contracts much easier to read and write."
>>
>> could be:
>>
>> "The D language supports Contract Programming by means of its in, out, and invariant constructs. Their current syntactic form is unnecessarily verbose. This DIP proposes improvements to the contract syntax that makes them easier to read and write."
>>
>> The change:
>>
>> * eliminates the entire "implementation sucks" allegation which seems taken straight from a forum flamewar;
>>
>> * replaces adjective-laden language with simple and precise statements;
>>
>> * provides a brief factual overview of what follows.
>>
>> Who wants to help?
>>
>>
>> Andrei
> 
> This actually makes the DIP slightly longer but hopefully makes it more clear.
> 
> https://github.com/dlang/DIPs/pull/95
> 
> I'm heading off to bed so I won't be able to respond right away to suggested changes.

Thanks! We're still looking for sizeable improvements. Any volunteers, please holler. -- Andrei