May 17, 2017
On Tuesday, 16 May 2017 at 18:06:38 UTC, Andrei Alexandrescu wrote:
> On 05/16/2017 01:59 PM, Random D user wrote:
>>
>> int foo()
>> in
>> {
>> }
>> out
>> {
>> }
>> do
>> {
>>   bar();
>> }
>
> Can't deny I like that. -- Andrei

I'll add this option to the DIP.
May 17, 2017
On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer wrote:
>>
>> 1) Consistency with functions without contracts.
>
> This only applies to the "naked" version which has ugly }{ in it. The other options people are asking about are replacing body with a keyword, which I think you agree would be bad for consistency?
>
I don't understand why this would be uglier than )( used in templates. Since imo it is one of the highlights of D to have "discovered" that one didn't need the super-ugly <> template pars of other languages, as the relative position in the code made it absolutely unambiguous which is which.
The same is true for function bodies. It is completely unambiguous where it starts and ends. As for }{, it would be rare anyway, as it would generally be written vertically
out {
  assert(whatever);
}
{
...
}

or even

out { assert(whatever);}
{
 ...
}


May 17, 2017
On 5/17/17 8:47 AM, Patrick Schluter wrote:
> On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer wrote:
>>>
>>> 1) Consistency with functions without contracts.
>>
>> This only applies to the "naked" version which has ugly }{ in it. The
>> other options people are asking about are replacing body with a
>> keyword, which I think you agree would be bad for consistency?
>>
> I don't understand why this would be uglier than )( used in templates.
> Since imo it is one of the highlights of D to have "discovered" that one
> didn't need the super-ugly <> template pars of other languages, as the
> relative position in the code made it absolutely unambiguous which is
> which.

Sure, it could be something we get used to.

However, since naked {} are generally treated as a new scope and valid in many places, it looks strange.

> The same is true for function bodies. It is completely unambiguous where
> it starts and ends. As for }{, it would be rare anyway, as it would
> generally be written vertically
> out {
>   assert(whatever);
> }
> {
> ....
> }
>
> or even
>
> out { assert(whatever);}
> {
>  ...
> }

This has been hashed out in this thread quite a bit. It's a perception thing, not really a technical problem. And my perception is that it's ugly :)

I think in practice, it would turn out probably fine.

-Steve
May 17, 2017
On 5/16/2017 12:48 PM, Timon Gehr wrote:
> It's a good option to have, but D is not an expression-based language, so this
> can be painful, as you cannot declare intermediate variables nor use statements.

You can by using lambdas, but embedded lambdas are rather awkward.
May 17, 2017
On 17.05.2017 14:47, Patrick Schluter wrote:
>>
> I don't understand why this would be uglier than )( used in templates.
.
This is a different case. In C-like languages '(' is essentially a binary operator and the second set of parens applies to the result of the first set. f(a)(b) is curried function application. The function body does not apply to the contract in any way, they are two syntactically independent constituents of the function declaration.

(Clearly, function template declaration syntax would be better as "void foo!(A,B,C)(A a, B b, C c){ ... }", but fixing this is perhaps not an option now.)
May 17, 2017
On 17.05.2017 18:23, Timon Gehr wrote:
> On 17.05.2017 14:47, Patrick Schluter wrote:
>>>
>> I don't understand why this would be uglier than )( used in templates.
> .
> This is a different case. In C-like languages '(' is essentially a
> binary operator ...

Or rather, a postfix operator.

May 17, 2017
On Wednesday, 17 May 2017 at 09:57:41 UTC, Basile B. wrote:
> On Wednesday, 17 May 2017 at 09:53:49 UTC, MysticZach wrote:
>> Option 4) Keep `body`, but make it both contextual *and* optional. It becomes usable as an identifier, and those who think it's unnecessary are appeased. The downside is that different programmers will include it or not, based on arbitrary preferences.
>
> The problem with this option is the IDEs. D syntax so far doesn't require parsing to highlight, i.e you have a token and you know what is it directly, and this without looking at the previous tokens (which is basically what parsing does, detect token patterns).

I don't feel like it's much of a problem:

1. I suspect a simple matching of the three tokens '}', 'body', '{' would detect it most of the time.

2. Without that, remove `body` from your highlighter's list of keywords. When used as a keyword, it's very conspicuous anyway. Code won't lose much readability with just this one word unlit.

3. If `body` were optional, probably a lot of people wouldn't be using it to begin with. I suspect that Jonathan and I are not alone in thinking that it's not just useless, it's annoying. Thus, only code that uses it would have this problem.

May 17, 2017
On Wed, May 17, 2017 at 05:06:40PM +0000, MysticZach via Digitalmars-d wrote: [...]
> 3. If `body` were optional, probably a lot of people wouldn't be using it to begin with. I suspect that Jonathan and I are not alone in thinking that it's not just useless, it's annoying. Thus, only code that uses it would have this problem.

FWIW, I also find it annoying. Very annoying, in fact.  The underlying gripe I have with it (apart from verbosity) is the asymmetry caused by the appearance of an extra(neous) keyword `body` in front of what is otherwise an undecorated {...} function body block, just because optional elements (in/out) were introduced.

In other words, what irks me is that when there are no contracts, you have this:

	auto func(...) { /* code */ }

But when there are contracts, not only do the contracts themselves appear (in {...} and/or out(...){...}), but an extraneous keyword `body` also appears. To put this in context, consider all the variations together:

	auto func(...)                            { /* code */ }
	auto func(...) in{...}               body { /* code */ }
	auto func(...)         out(...){...} body { /* code */ }
	auto func(...) in{...} out(...){...} body { /* code */ }

Notice how the appearance of `body` in the 2nd to 4th lines sticks out like a sore thumb.

Since in{...} and out(...){...} are optional elements, it would be more aesthetically pleasing if they did not also affect the syntax around them, e.g.:

	// Now they are truly optional, and the surrounding syntax
	// doesn't change by their presence/absence.
	auto func(...)                       { /* code */ }
	auto func(...) in{...}               { /* code */ }
	auto func(...)         out(...){...} { /* code */ }
	auto func(...) in{...} out(...){...} { /* code */ }

Alternatively, the asymmetry would be eliminated if `body` was a *required* keyword before the function body, e.g.:

	auto func(...)                       body { /* code */ }
	auto func(...) in{...}               body { /* code */ }
	auto func(...)         out(...){...} body { /* code */ }
	auto func(...) in{...} out(...){...} body { /* code */ }

But I doubt anyone here would agree to making `body` a required keyword when there are no contracts!


T

-- 
Unix is my IDE. -- Justin Whear
May 18, 2017
On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
> On Tuesday, 16 May 2017 at 18:06:38 UTC, Andrei Alexandrescu wrote:
>> On 05/16/2017 01:59 PM, Random D user wrote:
>>>
>>> int foo()
>>> in
>>> {
>>> }
>>> out
>>> {
>>> }
>>> do
>>> {
>>>   bar();
>>> }
>>
>> Can't deny I like that. -- Andrei
>
> I'll add this option to the DIP.

https://github.com/dlang/DIPs/pull/65
May 18, 2017
On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
> On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
>> I'll add this option to the DIP.
>
> https://github.com/dlang/DIPs/pull/65

I think ( http://forum.dlang.org/post/kybywnscisxpebezwyvk@forum.dlang.org ) represents yet another distinct option. i.e. continue to allow `body`, but make it optional, that is, you can simply omit it if you want, while also allowing it as an identifier.