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


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


 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