On Wednesday, October 05, 2016 02:11:14 Meta via Digitalmars-d wrote:
> I'm currently writing up a DIP to propose removing `body` as a keyword to allow it to be used for variable names, functions, etc. I'm looking for examples and contexts where `body` would normally be used as a variable, function name, alias, etc. This is what I have come up with off the top of my head:
>
> - In web programming where "body" is a required tag in any valid
> HTML document. Ex:
> - It is a name commonly used for XML tags and/or attributes
> - Physics simulations as well in astronomical contexts
> ("planetary bodyies", etc.)
> - Video games, such as referring to the player character's body

I think that the only case that I've run into where I'd want to use body as a symbol name would be http/e-mail messages, since they have a header and a body.

- Jonathan M Davis

On Thursday, October 06, 2016 05:25:19 Patrick Schluter via Digitalmars-d wrote:
> Sorry, I find the actual body without body keyword much more natural (i.e. intuitive) than having the body requiring it only when there are contracts. It would be even consistent with the template syntax where 1 parenthesis pair is runtime parameter and when there are 2 pairs template+runtime. The genious idea of D was to find that template parameter didn't require the abomination of alternate parenthesis < >. In the same vein, I'm sure that the body keyword is superfluous as the contract statements are unambiguously marked. That body keyword is so "un-D-ic" as it gets.

Yeah, the fact that the body keyword is not required normally but is when you have in/out contracts is annoying, completely aside from what the keyword used is. I don't care much about losing the name body to a keyword, but I definitely don't like that you have to use a keyword for a function body when you have in/out contracts. It doesn't seem like it should be necessary, and it's inconsistent with the normal case.

- Jonathan M Davis

On Thursday, 6 October 2016 at 06:38:06 UTC, Jonathan M Davis wrote:
> Yeah, the fact that the body keyword is not required normally but is when you have in/out contracts is annoying, completely aside from what the keyword used is. I don't care much about losing the name body to a keyword, but I definitely don't like that you have to use a keyword for a function body when you have in/out contracts. It doesn't seem like it should be necessary, and it's inconsistent with the normal case.
>
> - Jonathan M Davis

I agree 100%.

On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
> - Video games, such as referring to the player character's body

Many years ago I did a D port of the C-Dogs game from C to D and it was quite annoying to have to rename all the body variables to body_. It has happened in other contexts a few more times since.

On Wednesday, 5 October 2016 at 19:45:20 UTC, Basile B. wrote:
> In this case let's drop completely the contracts...you can put them in the body, at the beg or at the end...

Language support for contracts enables a super class to enforce contracts on its virtual methods.

On Friday, October 07, 2016 10:57:00 Nick Treleaven via Digitalmars-d wrote:
> On Wednesday, 5 October 2016 at 19:45:20 UTC, Basile B. wrote:
> > In this case let's drop completely the contracts...you can put them in the body, at the beg or at the end...
>
> Language support for contracts enables a super class to enforce contracts on its virtual methods.

It also allows the contracts to be effectively &&ed or ||ed when it comes to the in and out contracts on virtual functions (IIRC, in contracts are ||ed and out contracts are &&ed, but I can never remember and have to think it through every time it comes up).

In any case, having explicit in and out contracts make it possible to make them work correctly in the face of inheritance. And _in theory_ some aspects of in contracts could be checked at compile time, which would make them better than simply putting the assertions in the function body (though no such compile time checking is currently implemented). Also, _in theory_, it makes it possible to have the in and out contracts be compiled in or not based on how the caller is compiled rather than the function being called (which is really how it should work but unfortunately doesn't at present).

In practice, as it stands, aside from inheritance, I think that explicit in and out contracts are pointless, because the in contracts can just be done in the function body, and out contracts normally need to be handled by the unit tests instead of an explicit out contract anyway (since in most cases, what needs to be asserted about the result depends on knowing exactly what the input was and knowing what the correct result for that input is, whereas an out contract can only check for things that are true of all results). So, I pretty much never use in our out contracts.

But the inheritance case is why they're still worth having in the language even if they're mostly useless in practice.

What is theoretically more useful IMHO is invariants, but since they get called before opAssign, it doesn't work to have an invariante for a type that would ever be initialized with void or used with emplace. So, in practice, I think that invariants are useless too, unfortunately. And my past attempts to argue that the invariant shouldn't be called before opAssign failed. So, I never use invariants anymore either. :(

- Jonathan M Davis

On Wed, 05 Oct 2016 02:11:14 +0000, Meta wrote:

> I'm currently writing up a DIP to propose removing `body` as a keyword to allow it to be used for variable names, functions, etc. I'm looking for examples and contexts where `body` would normally be used as a variable, function name, alias, etc. This is what I have come up with off the top of my head:
> 
> - In web programming where "body" is a required tag in any valid HTML
> document. Ex:
> - It is a name commonly used for XML tags and/or attributes - Physics
> simulations as well in astronomical contexts ("planetary bodyies", etc.)
> - Video games, such as referring to the player character's body

I'm doing an SMTP server. I want to split a message into headers and body.