www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Examples Wanted: Usages of "body" as a Symbol Name

reply Meta <jared771 gmail.com> writes:
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
Oct 04 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 5 October 2016 at 02:11:14 UTC, 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 think you covered most of the cases. as for me, it is more than enough. as for my cases, physics engines suffers most: it is *so* natural to use "body" field/variable there... and so annoying to always add ugly "_" suffix.
Oct 04 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 05.10.2016 um 05:04 schrieb ketmar:
 On Wednesday, 5 October 2016 at 02:11:14 UTC, 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 think you covered most of the cases. as for me, it is more than enough. as for my cases, physics engines suffers most: it is *so* natural to use "body" field/variable there... and so annoying to always add ugly "_" suffix.
+1 to physics, but I also hit it frequently when writing compilers/parsers (function, loop bodies etc.) and other programming language related libraries (scripting interfaces/wrappers).
Oct 05 2016
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-10-05 04:11, Meta wrote:

 - 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
- D compiler implementing the "body" keyword ;) -- /Jacob Carlborg
Oct 05 2016
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Wednesday, 5 October 2016 at 02:11:14 UTC, 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
Physics libraries absolutely. https://github.com/d-gamedev-team/dchip/blob/55f43e5f0cf67c8bc190711b69eb16230fa6188e/src/dchip/cpBody.d#L184 https://github.com/d-gamedev-team/dbox/blob/6f81fe065abec1e7def44fc777c5d8e9da936104/examples/demo/tests/bodytypes.d#L103 And in various C / C++ libraries. It's rather annoying that body is taken, it's a fairly rarely used keyword in D but often used in other languages.
Oct 05 2016
parent rcorre <ryan rcorre.net> writes:
On Wednesday, 5 October 2016 at 12:02:21 UTC, Andrej Mitrovic 
wrote:
 On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
 [...]
Physics libraries absolutely. https://github.com/d-gamedev-team/dchip/blob/55f43e5f0cf67c8bc190711b69eb16230fa6188e/src/dchip/cpBody.d#L184 https://github.com/d-gamedev-team/dbox/blob/6f81fe065abec1e7def44fc777c5d8e9da936104/examples/demo/tests/bodytypes.d#L103 And in various C / C++ libraries. It's rather annoying that body is taken, it's a fairly rarely used keyword in D but often used in other languages.
I created D bindings for chipmunk (unlike dchip which reimplemented it in D) and I had to change a _lot_ of bodies: https://github.com/rcorre/chipmunkd/commit/d6bde5b649c70a53f4295f522e660fae3c1e740f
Oct 05 2016
prev sibling next sibling parent reply angel <andrey.gelman gmail.com> writes:
On Wednesday, 5 October 2016 at 02:11:14 UTC, 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
Really, why do we need a _body_ ? We have pre-condition and post-condition (in and out), everything else is a body. It is simply inconsistent - a regular function with no in and out blocks has no body block. Now one adds a pre-condition (and / or post-condition) - whoop - one needs to wrap the whole function body ... well in a body expression.
Oct 05 2016
parent reply Rory McGuire via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, Oct 5, 2016 at 5:32 PM, angel via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Wednesday, 5 October 2016 at 02:11:14 UTC, 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
Really, why do we need a _body_ ? We have pre-condition and post-condition (in and out), everything else is a body. It is simply inconsistent - a regular function with no in and out blocks has no body block. Now one adds a pre-condition (and / or post-condition) - whoop - one needs to wrap the whole function body ... well in a body expression.
Recently I've had to use scope_ a lot more often than body_ but reserved keywords are really annoying, so the less we have the better :D
Oct 05 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
On Wednesday, 5 October 2016 at 16:57:42 UTC, Rory McGuire wrote:
 On Wed, Oct 5, 2016 at 5:32 PM, angel via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
 [...]
 Really, why do we need a _body_ ?
 We have pre-condition and post-condition (in and out), 
 everything else is
 a body.
 It is simply inconsistent - a regular function with no in and 
 out blocks
 has no body block. Now one adds a pre-condition (and / or 
 post-condition) -
 whoop - one needs to wrap the whole function body ... well in 
 a body
 expression.
Recently I've had to use scope_ a lot more often than body_ but reserved keywords are really annoying, so the less we have the better :D
Agreed - I have exactly the same problem with "version", which is also really common for, well, to hold a version number of a component. Body is annoying too. But, can keywords actually sanely be removed from the language without breaking the world?
Oct 05 2016
next sibling parent reply default0 <Kevin.Labschek gmx.de> writes:
On Wednesday, 5 October 2016 at 17:14:04 UTC, Matthias Klumpp 
wrote:
 On Wednesday, 5 October 2016 at 16:57:42 UTC, Rory McGuire 
 wrote:
 On Wed, Oct 5, 2016 at 5:32 PM, angel via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
 [...]
 Really, why do we need a _body_ ?
 We have pre-condition and post-condition (in and out), 
 everything else is
 a body.
 It is simply inconsistent - a regular function with no in and 
 out blocks
 has no body block. Now one adds a pre-condition (and / or 
 post-condition) -
 whoop - one needs to wrap the whole function body ... well in 
 a body
 expression.
Recently I've had to use scope_ a lot more often than body_ but reserved keywords are really annoying, so the less we have the better :D
Agreed - I have exactly the same problem with "version", which is also really common for, well, to hold a version number of a component. Body is annoying too. But, can keywords actually sanely be removed from the language without breaking the world?
To answer the question: if you can make them contextual keywords instead of keywords, then yes. Naturally that will increase complexity for correct syntax highlighting and similar things one may want to do to D code.
Oct 05 2016
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 5 October 2016 at 17:17:32 UTC, default0 wrote:
 On Wednesday, 5 October 2016 at 17:14:04 UTC, Matthias Klumpp 
 wrote:
 On Wednesday, 5 October 2016 at 16:57:42 UTC, Rory McGuire 
 wrote:
 On Wed, Oct 5, 2016 at 5:32 PM, angel via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
 [...]
 Really, why do we need a _body_ ?
 We have pre-condition and post-condition (in and out), 
 everything else is
 a body.
 It is simply inconsistent - a regular function with no in 
 and out blocks
 has no body block. Now one adds a pre-condition (and / or 
 post-condition) -
 whoop - one needs to wrap the whole function body ... well 
 in a body
 expression.
Recently I've had to use scope_ a lot more often than body_ but reserved keywords are really annoying, so the less we have the better :D
Agreed - I have exactly the same problem with "version", which is also really common for, well, to hold a version number of a component. Body is annoying too. But, can keywords actually sanely be removed from the language without breaking the world?
To answer the question: if you can make them contextual keywords instead of keywords, then yes. Naturally that will increase complexity for correct syntax highlighting and similar things one may want to do to D code.
I know that Walter is against contextual keywords. We had a long discussion on this about attributes like nogc. I made a wiki trying to explain the reasoning behind it: http://wiki.dlang.org/Language_Designs_Explained#Why_don.27t_we_create_a_special_rule_in_the_syntax_to_handle_non-keyword_function_attributes_without_an_.27.40.27_character.3F In my opinion, having to write "body_" instead of "body" is a minor annoyance, but just minor. I'm not sold that contextual keywords are bad, but if they are, then this "keyword" problem is hard to solve, and the current solution isn't so bad. Also, there's alot of other important things to be done with D, I don't think this one is very high on the list.
Oct 05 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-10-05 19:14, Matthias Klumpp wrote:

 Agreed - I have exactly the same problem with "version", which is also
 really common for, well, to hold a version number of a component. Body
 is annoying too.

 But, can keywords actually sanely be removed from the language without
 breaking the world?
In Ruby most keywords are not reserved words. Example: class Foo def class end end When the compiler sees the second "class" it already knows that this is a method declaration because of the "def" keyword. Actually calling this method requires a receiver: class Foo def class end def bar class # this won't compile self.class # this will work since the compiler knows that is has to be a method call because of the dot end end In Scala it's possible to wrap a keyword in backticks, this is necessary to be able to call a Java method that uses a name that is a keyword in Scala but not in Java: // Java class Foo { void def () {} } // Scala val a = new Foo() a.`def`() -- /Jacob Carlborg
Oct 05 2016
next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg 
wrote:
 On 2016-10-05 19:14, Matthias Klumpp wrote:

 Agreed - I have exactly the same problem with "version", which 
 is also
 really common for, well, to hold a version number of a 
 component. Body
 is annoying too.

 But, can keywords actually sanely be removed from the language 
 without
 breaking the world?
In Ruby most keywords are not reserved words. Example: class Foo def class end end When the compiler sees the second "class" it already knows that this is a method declaration because of the "def" keyword. Actually calling this method requires a receiver: class Foo def class end def bar class # this won't compile self.class # this will work since the compiler knows that is has to be a method call because of the dot end end In Scala it's possible to wrap a keyword in backticks, this is necessary to be able to call a Java method that uses a name that is a keyword in Scala but not in Java: // Java class Foo { void def () {} } // Scala val a = new Foo() a.`def`()
To remove D's current keywords and add them to the syntax would be quite an undertaking I think. If someone was so inclined, they could take the full syntax as it exists today, and try to modify it so that the keywords would be removed and added to the applicable grammar rules. I'd be curious to see how this would change the syntax rules, if it would be ALOT more complicated or if it only added some minor complication. My gut says that this would explode in complexity, but maybe not? You'd also have to make sure that the new syntax is still unambiguous, there's probably tools that can verify this.
Oct 05 2016
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg 
wrote:
 On 2016-10-05 19:14, Matthias Klumpp wrote:

 Agreed - I have exactly the same problem with "version", which 
 is also
 really common for, well, to hold a version number of a 
 component. Body
 is annoying too.

 But, can keywords actually sanely be removed from the language 
 without
 breaking the world?
In Ruby most keywords are not reserved words. a.`def`()
D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.
Oct 05 2016
next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
 On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg 
 wrote:
 On 2016-10-05 19:14, Matthias Klumpp wrote:

 Agreed - I have exactly the same problem with "version", 
 which is also
 really common for, well, to hold a version number of a 
 component. Body
 is annoying too.

 But, can keywords actually sanely be removed from the 
 language without
 breaking the world?
In Ruby most keywords are not reserved words. a.`def`()
D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.
Yes the fact that D is context free is a very nice benefit and I can pretty much guarantee that D maintainers will never allow changing the syntax to break this. However, I believe a context-free grammar could support "contextual keywords". Note that the word "contextual" here is a bit misleading. For someone who really wanted to remove body as a keyword, I encourage them to try to modify the syntax and see if they can maintain the "context-free" grammar and without over complicating the syntax. I'm not sure if it's possible, but it might be. Anyone up for the challenge?
Oct 05 2016
prev sibling parent reply pineapple <meapineapple gmail.com> writes:
On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
 On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg 
 wrote:
 On 2016-10-05 19:14, Matthias Klumpp wrote:

 Agreed - I have exactly the same problem with "version", 
 which is also
 really common for, well, to hold a version number of a 
 component. Body
 is annoying too.

 But, can keywords actually sanely be removed from the 
 language without
 breaking the world?
In Ruby most keywords are not reserved words. a.`def`()
D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.
In general I don't think this is a problem, but `body` is an unconventional term to have as a keyword. The other keywords that are used for function contracts (`in` and `out`) are also used in other places - perhaps `body` could be deprecated and eventually removed in favor of using another keyword instead? Either another, different keyword that is less likely to collide with common attributes of user types, or an existing keyword not meaningful in the same context. There may also be a case for making `body` implicit - e.g. void func() in{ // }out{ // }body{ // } Would become void func() in{ // }out{ // }{ // } I don't think this is of critical importance, but dealing with this somehow would definitely be a step in the right direction.
Oct 05 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 5 October 2016 at 19:30:27 UTC, pineapple wrote:
 On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
 On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg 
 wrote:
 On 2016-10-05 19:14, Matthias Klumpp wrote:

 Agreed - I have exactly the same problem with "version", 
 which is also
 really common for, well, to hold a version number of a 
 component. Body
 is annoying too.

 But, can keywords actually sanely be removed from the 
 language without
 breaking the world?
In Ruby most keywords are not reserved words. a.`def`()
D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.
In general I don't think this is a problem, but `body` is an unconventional term to have as a keyword. The other keywords that are used for function contracts (`in` and `out`) are also used in other places - perhaps `body` could be deprecated and eventually removed in favor of using another keyword instead? Either another, different keyword that is less likely to collide with common attributes of user types, or an existing keyword not meaningful in the same context. There may also be a case for making `body` implicit - e.g. void func() in{ // }out{ // }body{ // } Would become void func() in{ // }out{ // }{ // } I don't think this is of critical importance, but dealing with this somehow would definitely be a step in the right direction.
Sorry Sophie, but do you really think that's consistent to have in{} out{} {} so the actual body without keyword ? In this case let's drop completely the contracts...you can put them in the body, at the beg or at the end...The syntax will be less sane but the 4 guys who need "body" as identifier will be happy...
Oct 05 2016
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 5 October 2016 at 19:45:20 UTC, Basile B. wrote:
 On Wednesday, 5 October 2016 at 19:30:27 UTC, pineapple wrote:
 On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
 On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg 
 wrote:
 On 2016-10-05 19:14, Matthias Klumpp wrote:

 Agreed - I have exactly the same problem with "version", 
 which is also
 really common for, well, to hold a version number of a 
 component. Body
 is annoying too.

 But, can keywords actually sanely be removed from the 
 language without
 breaking the world?
In Ruby most keywords are not reserved words. a.`def`()
D context free grammar allow fast highlighting. I understand that people who write scripts think that it won't change anything...but it's not the reality. D is a system programming language, people who use D can deal with code base > 60 Kloc. And we don't want to see such a change because you can't use "body" in your student project.
In general I don't think this is a problem, but `body` is an unconventional term to have as a keyword. The other keywords that are used for function contracts (`in` and `out`) are also used in other places - perhaps `body` could be deprecated and eventually removed in favor of using another keyword instead? Either another, different keyword that is less likely to collide with common attributes of user types, or an existing keyword not meaningful in the same context. There may also be a case for making `body` implicit - e.g. void func() in{ // }out{ // }body{ // } Would become void func() in{ // }out{ // }{ // } I don't think this is of critical importance, but dealing with this somehow would definitely be a step in the right direction.
Sorry Sophie, but do you really think that's consistent to have in{} out{} {} so the actual body without keyword ? In this case let's drop completely the contracts...you can put them in the body, at the beg or at the end...The syntax will be less sane but the 4 guys who need "body" as identifier will be happy...
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.
Oct 05 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Oct 05 2016
parent pineapple <meapineapple gmail.com> writes:
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%.
Oct 06 2016
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
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.
Oct 07 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Oct 07 2016
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 5 October 2016 at 02:11:14 UTC, 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'll be against this. Seriously is it the biggest problem you have with D ? Also, what I guess is that your DIP will not propose "body" to be removed from the keyword list. You'll propose that "body" will be a keyword only in certain contexts... and we have already talked about that. You will say that for example "win32" is already used as a special keyword in a versionExpression. And I'll tell you that "win32" is an identifier used as keyword, contextually, while for "body" it's the opposite: It's a keyword that you propose to use as identifier.
Oct 05 2016
parent Meta <jared771 gmail.com> writes:
On Wednesday, 5 October 2016 at 17:51:07 UTC, Basile B. wrote:
 I'll be against this. Seriously is it the biggest problem you 
 have with D ?
Not by a longshot
 Also, what I guess is that your DIP will not propose "body" to 
 be removed from the keyword list. You'll propose that "body" 
 will be a keyword only in certain contexts...
 and we have already talked about that. You will say that for 
 example "win32" is already used as a special keyword in a 
 versionExpression. And I'll tell you that "win32" is an 
 identifier used as keyword, contextually, while for "body" it's 
 the opposite: It's a keyword that you propose to use as 
 identifier.
Please hold the strawmen until the DIP is ready for public viewing.
Oct 05 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Oct 05 2016
prev sibling next sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
Oct 06 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
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.
Oct 16 2016