www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "body" keyword is unnecessary

reply Alvaro <alvaroDotSegura gmail.com> writes:
D already has a long list of keywords, reserved words can't be used as 
identifiers, which can be annoying. "body" in particular is a common 
noun that programmers would gladly use as a variable name in physics 
simulation, astronomy, mechanics, games, health, etc. I think "body" can 
be removed from D with no harm, and with the benefit of allowing the 
name as identifier.

Rationale: Functions in C and derived languages have always had a body 
and they never needed a keyword. In D, "body" is used to mark the actual 
body of a function after the optional "in" and/or "out" contract blocks. 
What is different in the body itself of a function with and without 
contracts to make one body{...} and the other {...}?

Example:

int myfunc(int x)
in{
     ...contract preconditions...
}
out (result){
     ...contract postconditions...
}
body{
     ...code...
}

But we don't write:

int myfunc(int x)
body{
     ...code...
}

The body keyword can be omitted and still interpret the code correctly 
given this rule: "An unnamed {...} block right after an in{} or out{} 
block when defining a function, MUST be the function's body". Thus, the 
above code would become:

int myfunc(int x)
in{
     ...contract preconditions...
}
out (result){
     ...contract postconditions...
}
{
     ...code...
}

and be perfectly understandable, with the benefit of one less keyword. 
The compiler, upon reading the opening "{" after the out block, would 
know it is the beginning of the function body.

Or I am missing something that would overcomplicate parsing, etc?

Best regards
Mar 23 2011
next sibling parent Trass3r <un known.com> writes:
Yep, this has been brought up at least once before.
Nothing has happened so far.
Mar 23 2011
prev sibling next sibling parent reply Bekenn <leaveme alone.com> writes:
Interestingly, you don't even have to remove "body" from the syntax to 
remove it as a keyword, as it's only used in this context (that I know 
of), where no other symbols make sense.
Mar 24 2011
parent Ary Manzana <ary esperanto.org.ar> writes:
On 3/24/11 4:02 AM, Bekenn wrote:

 Interestingly, you don't even have to remove "body" from the syntax to
 remove it as a keyword, as it's only used in this context (that I know
 of), where no other symbols make sense.


And oh so many keywords could be removed from the language if the 
compiler is smarter...

I was really amazed when I found out public, protected and private are 
methods in Ruby, not keywords. In fact, I don't know if a concept like 
keyword exists in Ruby... and this is soooo good... I use the name 
"body" for an HTTP response.

At all times, every compiler writer should take this into account:

"When we discovered Ruby, we realized that we’d found what we’d been 
looking for. More than any other language with which we have worked, 
Ruby stays out of your way. You can concentrate on solving the problem 
at hand, instead of struggling with compiler and language issues. That’s 
how it can help you become a better programmer: by giving you the chance 
to spend your time creating solutions for your users, not for the compiler.”
Mar 24 2011
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <ludwig informatik.uni-luebeck.de> writes:
I'm all for this change.

Since there are already similar differences between 1.0 and 2.0 (e.g. 
invariant()) and projects can be fixed by a more or less simple search 
and replace, this would be a cheap way to clean up a keyword that can 
truly get in your way (in contrast to some others that have already been 
removed).

Actually I think the only keywords that really got in my way were "body" 
and "function" - I now have modules named body_.d and function_.d
Mar 24 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Sönke Ludwig" <ludwig informatik.uni-luebeck.de> wrote in message 
news:imeqnd$12ss$1 digitalmars.com...

 I'm all for this change.

 Since there are already similar differences between 1.0 and 2.0 (e.g. 
 invariant()) and projects can be fixed by a more or less simple search and 
 replace, this would be a cheap way to clean up a keyword that can truly 
 get in your way (in contrast to some others that have already been 
 removed).

 Actually I think the only keywords that really got in my way were "body" 
 and "function" - I now have modules named body_.d and function_.d


I've had "unittest", "mixin" and "in" get in the way (but not in any way 
that was actualy a real problem, just a minor *minor* inconvenience).
Mar 24 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I definitely had "in" as a problem. Its because some people like to
use that in C code. (Qt being the most recent example).

I've also had issues with "string". That one can be common in C code.
Its a pretty bad habit of naming your variables for what type they are
instead of their purpose. I guess it fits into that whole "I'll hack
it just for now, and fix it never" mentality.
Mar 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 I definitely had "in" as a problem. Its because some people like to
 use that in C code. (Qt being the most recent example).
 
 I've also had issues with "string". That one can be common in C code.
 Its a pretty bad habit of naming your variables for what type they are
 instead of their purpose. I guess it fits into that whole "I'll hack
 it just for now, and fix it never" mentality.


_Any_ keyword can conflict with a variable name. Some - like const - aren't 
terribly likely to be names that a programmer will want to use for a variable, 
but most of them are. Well-selected keywords do a good job of describing what 
they're for - just like well-selected variable names. So, there's going to be 
some overlap between good keywords and good variable names. Such is life with  
pretty much any programming language. And taking code in one programming 
language with a certain set of keywords and porting it to another with a 
different set of keywords is bound to run into trouble from time to time.

Now, string is pretty bad on the whole, but then again, there are plenty of 
cases where you just don't care about what a string is for and str or string 
makes perfect sense (a prime example would be functions which operate on 
general strings - such as std.string). IIRC, there are parameters in std.array 
called array, simply because you don't care what the array is for. The fact 
that it's an array is all that matters.

Regardless, no matter what keywords a language picks, they'll conflict with 
variable names that programmers want to use unless they're complete gibberish 
such as aesnth or rcoevw, and such keywords would be _horrible_.

- Jonathan M Davis
Mar 24 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/24/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Now, string is pretty bad on the whole, but then again, there are plenty of
 cases where you just don't care about what a string is for.


You don't care now, but you'll care later when its time to fix a bug.
Sometimes, its obvious what a name is by looking at the function call,
e.g.:
arr = getArrayOfInts();

But if this call is buried somewhere in the midst of spaghetti code
inside another function, and arr is used 100 lines below, by the time
you see it again you'll forget what it is for or what it contains.

Small functions that have these kinds of names are okay. Its the long
ones that are the problem. And the long ones usually have a multitude
of names like that. So you end up reading code written like this:

arr1 += arr3 * j / k;

Saves you a few seconds while writing, but makes you lose a lot of
time when trying to understand this code a few months down the road.
Mar 24 2011
prev sibling next sibling parent reply piotrek <starpit tlen.pl> writes:
On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:


 D already has a long list of keywords, reserved words can't be used as
 identifiers, which can be annoying. "body" in particular is a common
 noun that programmers would gladly use as a variable name in physics
 simulation, astronomy, mechanics, games, health, etc. I think "body" can
 be removed from D with no harm, and with the benefit of allowing the
 name as identifier.


yes, please

body is also a html tag

Cheers
Piotrek
Mar 24 2011
parent reply sclytrack <sclytrack superidiot.com> writes:
== Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used as
 identifiers, which can be annoying. "body" in particular is a common
 noun that programmers would gladly use as a variable name in physics
 simulation, astronomy, mechanics, games, health, etc. I think "body" can
 be removed from D with no harm, and with the benefit of allowing the
 name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


Copied the following line from the Vala (=mostly reference counted language)
web page.

"It is possible to use a reserved keyword as identifier name by prefixing it
with
the   character. This character is not part of the name. For example, you can
name
a method foreach by writing  foreach, even though this is a reserved Vala
keyword."

My body is hungry and starving.
Mar 24 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
sclytrack:


 Copied the following line from the Vala (=mostly reference counted language)
web page.
 
 "It is possible to use a reserved keyword as identifier name by prefixing it
with
 the   character. This character is not part of the name. For example, you can
name
 a method foreach by writing  foreach, even though this is a reserved Vala
keyword."





The prefix " " enables the use of keywords as identifiers, which is useful when
interfacing with other programming languages. The character   is not actually
part of the identifier, so the identifier might be seen in other languages as a
normal identifier, without the prefix. An identifier with an   prefix is called
a verbatim identifier. Use of the   prefix for identifiers that are not
keywords is permitted, but strongly discouraged as a matter of style.<


http://msdn.microsoft.com/en-us/library/aa664670%28v=vs.71%29.aspx

Bye,
bearophile
Mar 24 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used as
 identifiers, which can be annoying. "body" in particular is a common
 noun that programmers would gladly use as a variable name in physics
 simulation, astronomy, mechanics, games, health, etc. I think "body" can
 be removed from D with no harm, and with the benefit of allowing the
 name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted language)
web page.

 "It is possible to use a reserved keyword as identifier name by prefixing it
with
 the   character. This character is not part of the name. For example, you can
name
 a method foreach by writing  foreach, even though this is a reserved Vala
keyword."

 My body is hungry and starving.


How is this better than _body or body_?
Mar 24 2011
parent reply piotrek <starpit tlen.pl> writes:
On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:


 On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used
 as identifiers, which can be annoying. "body" in particular is a
 common noun that programmers would gladly use as a variable name in
 physics simulation, astronomy, mechanics, games, health, etc. I think
 "body" can be removed from D with no harm, and with the benefit of
 allowing the name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted
 language) web page.

 "It is possible to use a reserved keyword as identifier name by
 prefixing it with the   character. This character is not part of the
 name. For example, you can name a method foreach by writing  foreach,
 even though this is a reserved Vala keyword."

 My body is hungry and starving.


 How is this better than _body or body_?


I think " " is a little bit nicer, but it doesn't change the situation at all .
body (if possible) shouldn't be a keyword.
Can anyone from the steering group state his opinion? :)

Cheers,
Piotrek
Mar 24 2011
next sibling parent reply Don <nospam nospam.com> writes:
piotrek wrote:

 On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:
 

 On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used
 as identifiers, which can be annoying. "body" in particular is a
 common noun that programmers would gladly use as a variable name in
 physics simulation, astronomy, mechanics, games, health, etc. I think
 "body" can be removed from D with no harm, and with the benefit of
 allowing the name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted
 language) web page.

 "It is possible to use a reserved keyword as identifier name by
 prefixing it with the   character. This character is not part of the
 name. For example, you can name a method foreach by writing  foreach,
 even though this is a reserved Vala keyword."

 My body is hungry and starving.


 How is this better than _body or body_?


 
 I think " " is a little bit nicer, but it doesn't change the situation at all
. body (if possible) shouldn't be a keyword.
 Can anyone from the steering group state his opinion? :)


What's the steering group?
I raised this exact topic before, with the title "my body is ugly" <g>.
It's a very silly keyword. It's just a comment, really /*body*/.
Mar 24 2011
parent reply piotrek <starpit tlen.pl> writes:
On Thu, 24 Mar 2011 16:04:25 +0100, Don wrote:


 piotrek wrote:

 On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:
 

 On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used
 as identifiers, which can be annoying. "body" in particular is a
 common noun that programmers would gladly use as a variable name in
 physics simulation, astronomy, mechanics, games, health, etc. I
 think "body" can be removed from D with no harm, and with the
 benefit of allowing the name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted
 language) web page.

 "It is possible to use a reserved keyword as identifier name by
 prefixing it with the   character. This character is not part of the
 name. For example, you can name a method foreach by writing  foreach,
 even though this is a reserved Vala keyword."

 My body is hungry and starving.


 How is this better than _body or body_?


 
 I think " " is a little bit nicer, but it doesn't change the situation
 at all . body (if possible) shouldn't be a keyword. Can anyone from the
 steering group state his opinion? :)


 
 What's the steering group?


I think you belong there. :) Along with Walter, Andrei, Brad and Sean.
Of course support of  David, Steven, Lars and Jonathan and the 
whole community is invaluable. :)


 I raised this exact topic before, with the title "my body is ugly" <g>.
 It's a very silly keyword. It's just a comment, really /*body*/.


What stops Walter from removing it? If it was me, the next dmd 
release would have one keyword less ;) (Forget for a while that
I'm not familiar with the dmd code)

Cheers,
Piotrek
Mar 24 2011
parent reply Don <nospam nospam.com> writes:
piotrek wrote:

 On Thu, 24 Mar 2011 16:04:25 +0100, Don wrote:
 

 piotrek wrote:

 On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:


 On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used
 as identifiers, which can be annoying. "body" in particular is a
 common noun that programmers would gladly use as a variable name in
 physics simulation, astronomy, mechanics, games, health, etc. I
 think "body" can be removed from D with no harm, and with the
 benefit of allowing the name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted
 language) web page.

 "It is possible to use a reserved keyword as identifier name by
 prefixing it with the   character. This character is not part of the
 name. For example, you can name a method foreach by writing  foreach,
 even though this is a reserved Vala keyword."

 My body is hungry and starving.


 How is this better than _body or body_?


 I think " " is a little bit nicer, but it doesn't change the situation
 at all . body (if possible) shouldn't be a keyword. Can anyone from the
 steering group state his opinion? :)


 What's the steering group?


 
 I think you belong there. :) Along with Walter, Andrei, Brad and Sean.
 Of course support of  David, Steven, Lars and Jonathan and the 
 whole community is invaluable. :)


Walter makes all the language decisions. The rest of us have just been 
able to convince him on multiple occasions (but I think that even Andrei 


chance if you make a patch, but ONLY if you've satisfied hint 1.


 I raised this exact topic before, with the title "my body is ugly" <g>.
 It's a very silly keyword. It's just a comment, really /*body*/.


 
 What stops Walter from removing it? If it was me, the next dmd 
 release would have one keyword less ;) (Forget for a while that
 I'm not familiar with the dmd code)


Priorities. If you spend any time on 'body', that's time taken away from 
fixing important bugs. The potential benefit is *tiny*. There are 1000 
bugs that are more important.
Mar 25 2011
next sibling parent reply piotrek <starpit tlen.pl> writes:
On Fri, 25 Mar 2011 10:09:25 +0100, Don wrote:


 piotrek wrote:

 On Thu, 24 Mar 2011 16:04:25 +0100, Don wrote:
 

 piotrek wrote:

 On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:


 On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be
 used as identifiers, which can be annoying. "body" in particular
 is a common noun that programmers would gladly use as a variable
 name in physics simulation, astronomy, mechanics, games, health,
 etc. I think "body" can be removed from D with no harm, and with
 the benefit of allowing the name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted
 language) web page.

 "It is possible to use a reserved keyword as identifier name by
 prefixing it with the   character. This character is not part of
 the name. For example, you can name a method foreach by writing
  foreach, even though this is a reserved Vala keyword."

 My body is hungry and starving.


 How is this better than _body or body_?


 I think " " is a little bit nicer, but it doesn't change the
 situation at all . body (if possible) shouldn't be a keyword. Can
 anyone from the steering group state his opinion? :)


 What's the steering group?


 
 I think you belong there. :) Along with Walter, Andrei, Brad and Sean.
 Of course support of  David, Steven, Lars and Jonathan and the whole
 community is invaluable. :)


 
 Walter makes all the language decisions. The rest of us have just been
 able to convince him on multiple occasions (but I think that even Andrei


 chance if you make a patch, but ONLY if you've satisfied hint 1.
 


The way the D is managed (in term of language specification) is the key to
its success. Walter is like a solid rock. e.g. If he did what bearophile 
suggests (respect for his work for polishing D) it would be a disaster ;)

BTW.
I think it would be great if I fall into compiler mechanics, but don't see
any chances in the nearest future.


 I raised this exact topic before, with the title "my body is ugly"
 <g>. It's a very silly keyword. It's just a comment, really /*body*/.


 
 What stops Walter from removing it? If it was me, the next dmd release
 would have one keyword less ;) (Forget for a while that I'm not
 familiar with the dmd code)


 
 Priorities. If you spend any time on 'body', that's time taken away from
 fixing important bugs. The potential benefit is *tiny*. There are 1000
 bugs that are more important.


So true. You know, after writing my posts I felt guilty because it could be 
rated as arrogant. I really appreciate Walter's work and didn't want 
to make any pressure on him (like I could ;). I'm grateful for him for all
amazing staff he did. D is the most beautiful language I have seen. It
has its pitfalls, but we know there can't be any perfect one. For now we
can live with our "body" :)
Speaking of real world examples(is my world really real? :D)
I hit "body" when I was doing an html generator. Long before that when 
I was reading language specification I looked with distaste at the "body" 
keyword in the contract programming section. Still no big deal.

Cheers,
Piotrek
Mar 25 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/25/2011 2:40 PM, piotrek wrote:

 I really appreciate Walter's work and didn't want
 to make any pressure on him (like I could ;). I'm grateful for him for all
 amazing staff he did. D is the most beautiful language I have seen. It
 has its pitfalls, but we know there can't be any perfect one. For now we
 can live with our "body" :)



Thanks for the kind words. Not everyone thinks that way

http://www.reddit.com/r/programming/comments/gacna/bye_bye_nullpointerexceptions/c1m3r7n

:-)
Mar 25 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Thanks for the kind words. Not everyone thinks that way
 
 http://www.reddit.com/r/programming/comments/gacna/bye_bye_nullpointerexceptions/c1m3r7n
 
 :-)


I didn't see that thread, thank you for the link. Some of your answers shown in
that Reddit page were really wrong (like that "null pointer exception is
reinvented"), I hope you know better now.

About the notnulls topic, I have expressed my point of view some times, I think
a notnull suffix syntax for pointers/object references, plus a bit of type
state semantics are able to avoid most problems caused by nulls.

Regarding your "dynamite general case solution", that probably Andrei too was
referring with "working on a  disable property that will allow non-null types
to be implemented as a library-defined type constructor." I remember some
people in this newsgroup appreciating the idea, but I didn't understand it
much. Null-derived bugs are indeed only one special case of bugs that are
avoided in languages like Haskell, and by good typestate-based languages, so a
more general solution for them all will be good. But on the other hand there is
the risk of over-generalization: null-caused bugs are the most common in that
class of related bugs, so maybe a solution that's focused only on null-related
bugs can be better and simpler, both syntax-wise and regarding how much handy
it is to use *everywhere* (because you want to use it everywhere in OOP
programs and even on programs that use pointers. My suggestion was about
notnullable raw pointers too). So I will wait for a more defined explanation of
this  disable idea, to comment some more.

Bye,
bearophile
Mar 25 2011
prev sibling parent reply Alvaro <alvaroDotSegura gmail.com> writes:
El 25/03/2011 22:40, piotrek escribió:


 Speaking of real world examples(is my world really real? :D)
 I hit "body" when I was doing an html generator. Long before that when
 I was reading language specification I looked with distaste at the "body"
 keyword in the contract programming section. Still no big deal.


A bit off-topic post:

I first hit "body" when porting the nbody benchmark test from the 
Computer Language Shootout to D.

http://shootout.alioth.debian.org/u32/performance.php?test=nbody#about

I wanted to write things like:

foreach (ref body; bodies) {
	body.x += dt * body.vx;
	body.y += dt * body.vy;
	body.z += dt * body.vz;
}

BTW, in that benchmark D, with my clean implementation, would perform 
similar to "Clean", about 1.7x slower than the fastest, Fortran. That is 
with GDC and all optimizations. DMD a bit behind with a 2.1x elapsed 
time. Both are behind Java, C and C++.
Mar 26 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Alvaro:


 A bit off-topic post:


It's not off-topic, you have shown one case where the keyword "body" is useful
as variable name.



 I first hit "body" when porting the nbody benchmark test from the 
 Computer Language Shootout to D.


Time ago I have translated to D (D1, mostly) all Shootout benchmarks. Here you
see two versions:
http://shootout.alioth.debian.org/debian/performance.php?test=nbody

 

 BTW, in that benchmark D, with my clean implementation, would perform 
 similar to "Clean", about 1.7x slower than the fastest, Fortran. That is 
 with GDC and all optimizations. DMD a bit behind with a 2.1x elapsed 
 time. Both are behind Java, C and C++.


Fortran was designed to run as fast as possible right this kind of programs.
D1 code compiled with LDC is about as fast as naive C n-body code (I have said
naive version because in D you can't use intrinsics as __builtin_ia32_sqrtpd()
as in one more advanced C++ version).

Bye,
bearophile
Mar 26 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/25/2011 2:09 AM, Don wrote:

 Walter makes all the language decisions. The rest of us have just been able to
 convince him on multiple occasions (but I think that even Andrei has not


 but ONLY if you've satisfied hint 1.


Nobody would like it if I was easy to convince. There are multiple language 
change suggestions here *every day*. Day after day, that adds up to a 
frightening number.

To make a language change stick, it has to have a large benefit divided by its 
cost. Costs for even small changes can be huge - implementation, testing, 
documentation, tutorials, books, existing code base, distraction from other 
issues, instability, regressions, etc.



 Priorities. If you spend any time on 'body', that's time taken away from fixing
 important bugs. The potential benefit is *tiny*. There are 1000 bugs that are
 more important.


Right. I'm currently working on the temp destruction problem. While not sexy or 
even particularly visible, it not working right has serious deleterious 
consequences.
Mar 25 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 24, 11 22:25, piotrek wrote:

 On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:


 On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used
 as identifiers, which can be annoying. "body" in particular is a
 common noun that programmers would gladly use as a variable name in
 physics simulation, astronomy, mechanics, games, health, etc. I think
 "body" can be removed from D with no harm, and with the benefit of
 allowing the name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted
 language) web page.

 "It is possible to use a reserved keyword as identifier name by
 prefixing it with the   character. This character is not part of the
 name. For example, you can name a method foreach by writing  foreach,
 even though this is a reserved Vala keyword."

 My body is hungry and starving.


 How is this better than _body or body_?


 I think " " is a little bit nicer, but it doesn't change the situation at all
. body (if possible) shouldn't be a keyword.
 Can anyone from the steering group state his opinion? :)

 Cheers,
 Piotrek


I agree body shouldn't be a keyword.

The  body solution doesn't work in D because:
   1.  identifier is already reserved for user attributes ( safe, etc.)
   2. What does  keyword.stringof (name of the variable) return?
       if it returns " keyword", then it is no different from using 
"_keyword"
       if it returns "keyword", you may break many string mixins.


would be got used. D shouldn't have this problem.

------

Speaking of which, how do we do

     extern(C) void body();

?
Mar 24 2011
parent piotrek <starpit tlen.pl> writes:
On Fri, 25 Mar 2011 00:50:56 +0800, KennyTM~ wrote:


 On Mar 24, 11 22:25, piotrek wrote:

 On Thu, 24 Mar 2011 21:37:12 +0800, KennyTM~ wrote:


 On Mar 24, 11 19:00, sclytrack wrote:

 == Quote from piotrek (starpit tlen.pl)'s article

 On Wed, 23 Mar 2011 23:17:32 +0100, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used
 as identifiers, which can be annoying. "body" in particular is a
 common noun that programmers would gladly use as a variable name in
 physics simulation, astronomy, mechanics, games, health, etc. I
 think "body" can be removed from D with no harm, and with the
 benefit of allowing the name as identifier.


 yes, please
 body is also a html tag
 Cheers
 Piotrek


 Copied the following line from the Vala (=mostly reference counted
 language) web page.

 "It is possible to use a reserved keyword as identifier name by
 prefixing it with the   character. This character is not part of the
 name. For example, you can name a method foreach by writing  foreach,
 even though this is a reserved Vala keyword."

 My body is hungry and starving.


 How is this better than _body or body_?


 I think " " is a little bit nicer, but it doesn't change the situation
 at all . body (if possible) shouldn't be a keyword. Can anyone from the
 steering group state his opinion? :)

 Cheers,
 Piotrek


 
 I agree body shouldn't be a keyword.
 
 The  body solution doesn't work in D because:
 ...


Yes I know. I was only referring to how it looks.
I'm allergic to the underscore char in programming languages ;)
"better" in my previous post was like:
2 cents are "better" than 1 cent and I can have 1 million dollars.
So why would I want " body" if I can have "body".
 body was just useless noise.

Cheers,
Piotrek
Mar 24 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 23 Mar 2011 18:17:32 -0400, Alvaro <alvaroDotSegura gmail.com>  
wrote:


 D already has a long list of keywords, reserved words can't be used as  
 identifiers, which can be annoying. "body" in particular is a common  
 noun that programmers would gladly use as a variable name in physics  
 simulation, astronomy, mechanics, games, health, etc. I think "body" can  
 be removed from D with no harm, and with the benefit of allowing the  
 name as identifier.

 Rationale: Functions in C and derived languages have always had a body  
 and they never needed a keyword. In D, "body" is used to mark the actual  
 body of a function after the optional "in" and/or "out" contract blocks.  
 What is different in the body itself of a function with and without  
 contracts to make one body{...} and the other {...}?

 Example:

 int myfunc(int x)
 in{
      ...contract preconditions...
 }
 out (result){
      ...contract postconditions...
 }
 body{
      ...code...
 }

 But we don't write:

 int myfunc(int x)
 body{
      ...code...
 }

 The body keyword can be omitted and still interpret the code correctly  
 given this rule: "An unnamed {...} block right after an in{} or out{}  
 block when defining a function, MUST be the function's body". Thus, the  
 above code would become:

 int myfunc(int x)
 in{
      ...contract preconditions...
 }
 out (result){
      ...contract postconditions...
 }
 {
      ...code...
 }

 and be perfectly understandable, with the benefit of one less keyword.  
 The compiler, upon reading the opening "{" after the out block, would  
 know it is the beginning of the function body.

 Or I am missing something that would overcomplicate parsing, etc?


Most likely it's not necessary.

But I don't know that it's so terrible to have it as a keyword.  Clearly  
there was a "free keyword love" period in D's past, but I think it takes a  
lot more than just "we could technically do this without a keyword" to  
remove it from the language.  For one, it would break tons of existing  
code.


inside properties).

One thing it does help with is it provides a visual (and searchable)  
anchor for a person reading a function.  For example if preconditions and  
postconditions come before the body and are quite long, being able to do  
/body in vi is nice.  It also would seem like something was missing if it  
was just blank (of course, only when the in/out contracts are there).

-Steve
Mar 24 2011
parent Bekenn <leaveme alone.com> writes:
On 3/24/2011 12:55 PM, Steven Schveighoffer wrote:


 inside properties).


This is exactly what it should be.
Mar 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-24 16:23:40, Andrej Mitrovic wrote:

 On 3/24/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Now, string is pretty bad on the whole, but then again, there are plenty
 of cases where you just don't care about what a string is for.


 
 You don't care now, but you'll care later when its time to fix a bug.
 Sometimes, its obvious what a name is by looking at the function call,
 e.g.:
 arr = getArrayOfInts();
 
 But if this call is buried somewhere in the midst of spaghetti code
 inside another function, and arr is used 100 lines below, by the time
 you see it again you'll forget what it is for or what it contains.
 
 Small functions that have these kinds of names are okay. Its the long
 ones that are the problem. And the long ones usually have a multitude
 of names like that. So you end up reading code written like this:
 
 arr1 += arr3 * j / k;
 
 Saves you a few seconds while writing, but makes you lose a lot of
 time when trying to understand this code a few months down the road.


You don't care when it doesn't matter one whit what the variable is for - only 
what its type is. Take one of the signatures for std.array.insert for example:

void insert(T, Range)(ref T[] array, size_t pos, Range stuff)
if (isInputRange!Range && is(ElementEncodingType!Range : T))


The array is called array. This is because that's all you care about. It's the 
array that you're processing. The whole point of the function is to insert 
into an array. So, the fact that it is an array is what is important. There 
arguably isn't a better name. The length of the function is irrelevant.

Most functions, on the other hand, are trying to do something with much more 
semantic meaning to it and _do_ care about what is in the variable. In _those_ 
functions, names like array or string are horrible. You want names which 
actually indicate what the variable is _for_.

So, in most cases, I would agree with you that variable names like array are 
horrible. However, there _are_ certain types of functions where you _can't_ 
really give a better name, because the type of the variable is _all_ that 
matters. That's why you have std.array functions with a parameter called array 
or std.range functions with a parameter called range or r. What the variable 
is _for_ is irrelevant at that point. You just don't care. All that matters is 
what type is. But that is not the norm for variable names by any means.

- Jonathan M Davis
Mar 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-24 16:23:40, Andrej Mitrovic wrote:

 On 3/24/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Now, string is pretty bad on the whole, but then again, there are plenty
 of cases where you just don't care about what a string is for.


 
 You don't care now, but you'll care later when its time to fix a bug.
 Sometimes, its obvious what a name is by looking at the function call,
 e.g.:
 arr = getArrayOfInts();
 
 But if this call is buried somewhere in the midst of spaghetti code
 inside another function, and arr is used 100 lines below, by the time
 you see it again you'll forget what it is for or what it contains.
 
 Small functions that have these kinds of names are okay. Its the long
 ones that are the problem. And the long ones usually have a multitude
 of names like that. So you end up reading code written like this:
 
 arr1 += arr3 * j / k;
 
 Saves you a few seconds while writing, but makes you lose a lot of
 time when trying to understand this code a few months down the road.


You don't care when it doesn't matter one whit what the variable is for - only 
what its type is. Take one of the signatures for std.array.insert for example:

void insert(T, Range)(ref T[] array, size_t pos, Range stuff)
if (isInputRange!Range && is(ElementEncodingType!Range : T))


The array is called array. This is because that's all you care about. It's the 
array that you're processing. The whole point of the function is to insert 
into an array. So, the fact that it is an array is what is important. There 
arguably isn't a better name. The length of the function is irrelevant.

Most functions, on the other hand, are trying to do something with much more 
semantic meaning to it and _do_ care about what is in the variable. In _those_ 
functions, names like array or string are horrible. You want names which 
actually indicate what the variable is _for_.

So, in most cases, I would agree with you that variable names like array are 
horrible. However, there _are_ certain types of functions where you _can't_ 
really give a better name, because the type of the variable is _all_ that 
matters. That's why you have std.array functions with a parameter called array 
or std.range functions with a parameter called range or r. What the variable 
is _for_ is irrelevant at that point. You just don't care. All that matters is 
what type is. But that is not the norm for variable names by any means.

- Jonathan M Davis
Mar 24 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/25/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 snip


Well, I was really referring to C client-code, not templated D library
code, maybe I should have made myself more clear on that :)

Generic code uses generic names, it makes the most sense there. So I
agree with everything you've said.
Mar 25 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/23/2011 3:17 PM, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used as
 identifiers, which can be annoying. "body" in particular is a common noun that
 programmers would gladly use as a variable name in physics simulation,
 astronomy, mechanics, games, health, etc. I think "body" can be removed from D
 with no harm, and with the benefit of allowing the name as identifier.


Body is not strictly necessary to parse it. But it makes for a nice "anchor" 
when the in and out clauses get long.

In any case, we are currently working on getting temp destruction to work 
correctly, and after that we'll work on fixing issues with const. I think these 
are the most important things we should be working on at the moment.
Mar 27 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-27 22:23, Walter Bright wrote:

 On 3/23/2011 3:17 PM, Alvaro wrote:

 D already has a long list of keywords, reserved words can't be used as
 identifiers, which can be annoying. "body" in particular is a common noun
 that programmers would gladly use as a variable name in physics
 simulation, astronomy, mechanics, games, health, etc. I think "body" can
 be removed from D with no harm, and with the benefit of allowing the
 name as identifier.


 
 Body is not strictly necessary to parse it. But it makes for a nice
 "anchor" when the in and out clauses get long.
 
 In any case, we are currently working on getting temp destruction to work
 correctly, and after that we'll work on fixing issues with const. I think
 these are the most important things we should be working on at the moment.


I'll be _very_ excited to have both the destructor issues and the const issues 
sorted out. They are some of the more annoying quality of implementation 
issues at the moment.

I'm not against body no longer being a keyword if it's reasonable to leave the 
language as-is, as has been suggested here, and not have body be a keyword, 
but I have to concur that it's not exactly a high priority issue. However, 
it's much easier to discuss, which is probably part of the reason that it's 
being discussed so much.

Then again, in many cases at this point, what we need isn't really more 
suggestions on how to improve the language or libraries but help in 
implementing improvements. Suggestions are by no means bad, but given 
everything else that needs doing and how few people there are to do it, 
suggestions are not likely to be implemented soon, even if they're good.

If no one has done so already, this suggestion would be worth creating an 
enhancement request in bugzilla for, but I'd much rather see other quality of 
implementation issues fixed rather than have such an enhancement implemented 
right now. The enhancement is nicely backwards compatible, so it can be done 
at any point in time later without breaking any code or having to way for a 
possible D3.

- Jonathan M Davis
Mar 27 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2011 10:35 PM, Jonathan M Davis wrote:

 I'll be _very_ excited to have both the destructor issues and the const issues
 sorted out. They are some of the more annoying quality of implementation
 issues at the moment.


Yes, I agree those are the top priority at the moment, now that we have the 64 
bit compiler online and the worst of the optlink issues resolved.
Mar 28 2011
next sibling parent "Vlad" <b100dian gmail.com> writes:
Hate to reopen old threads.. but I didn't find another one on 
this topic.

Supposing someone wants to implement a browser in D.
And his bindings to JavaScript need to expose HTMLDocument.body 
property.
Is that a use case that would work for allowing body not to be a 
keyword?

--
Vlad
Jul 28 2013
prev sibling parent reply Eljay <eljay.adobe gmail.com> writes:
On Monday, 28 March 2011 at 18:59:03 UTC, Walter Bright wrote:

 On 3/27/2011 10:35 PM, Jonathan M Davis wrote:

 I'll be _very_ excited to have both the destructor issues and 
 the const issues
 sorted out. They are some of the more annoying quality of 
 implementation
 issues at the moment.


 Yes, I agree those are the top priority at the moment, now that 
 we have the 64 bit compiler online and the worst of the optlink 
 issues resolved.


NECRO ALERT...

But I just saw that 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md was 
addressed with https://github.com/dlang/dmd/pull/6855 .

I, for one, will miss 'body' the keyword.  Now I'll have to 
update all my toy code.

(Just kidding, I don't mind updating my toy code.  At least it 
isn't a codebase the size of Photoshop!)
Nov 18 2017
next sibling parent bauss <jj_1337 live.dk> writes:
On Saturday, 18 November 2017 at 16:21:30 UTC, Eljay wrote:

 On Monday, 28 March 2011 at 18:59:03 UTC, Walter Bright wrote:

 On 3/27/2011 10:35 PM, Jonathan M Davis wrote:

 [...]


 Yes, I agree those are the top priority at the moment, now 
 that we have the 64 bit compiler online and the worst of the 
 optlink issues resolved.


 NECRO ALERT...

 But I just saw that 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md was 
 addressed with https://github.com/dlang/dmd/pull/6855 .

 I, for one, will miss 'body' the keyword.  Now I'll have to 
 update all my toy code.

 (Just kidding, I don't mind updating my toy code.  At least it 
 isn't a codebase the size of Photoshop!)


It would be easy to update anyway. Scan for body statements in 
your code and just replace it lol.
Nov 18 2017
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 18 November 2017 at 16:21:30 UTC, Eljay wrote:

 On Monday, 28 March 2011 at 18:59:03 UTC, Walter Bright wrote:

 On 3/27/2011 10:35 PM, Jonathan M Davis wrote:

 I'll be _very_ excited to have both the destructor issues and 
 the const issues
 sorted out. They are some of the more annoying quality of 
 implementation
 issues at the moment.


 Yes, I agree those are the top priority at the moment, now 
 that we have the 64 bit compiler online and the worst of the 
 optlink issues resolved.


 NECRO ALERT...

 But I just saw that 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md was 
 addressed with https://github.com/dlang/dmd/pull/6855 .

 I, for one, will miss 'body' the keyword.  Now I'll have to 
 update all my toy code.

 (Just kidding, I don't mind updating my toy code.  At least it 
 isn't a codebase the size of Photoshop!)


Don't worry, you've got a few years yet. Currently `body`is not 
even deprecated; it's become a conditional keyword, or you can 
use `do` in its place.
Nov 18 2017
next sibling parent reply Tony <tonytdominguez aol.com> writes:
On Saturday, 18 November 2017 at 19:22:25 UTC, Meta wrote:

 On Saturday, 18 November 2017 at 16:21:30 UTC, Eljay wrote:

 On Monday, 28 March 2011 at 18:59:03 UTC, Walter Bright wrote:

 On 3/27/2011 10:35 PM, Jonathan M Davis wrote:

 I'll be _very_ excited to have both the destructor issues 
 and the const issues
 sorted out. They are some of the more annoying quality of 
 implementation
 issues at the moment.


 Yes, I agree those are the top priority at the moment, now 
 that we have the 64 bit compiler online and the worst of the 
 optlink issues resolved.


 NECRO ALERT...

 But I just saw that 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md was 
 addressed with https://github.com/dlang/dmd/pull/6855 .

 I, for one, will miss 'body' the keyword.  Now I'll have to 
 update all my toy code.

 (Just kidding, I don't mind updating my toy code.  At least it 
 isn't a codebase the size of Photoshop!)


 Don't worry, you've got a few years yet. Currently `body`is not 
 even deprecated; it's become a conditional keyword, or you can 
 use `do` in its place.


It may be deprecated, but someone completely removed it from the 
documentation on contracts. That could cause some confusion for 
people using older versions of the compiler.

https://dlang.org/spec/contracts.html
Nov 18 2017
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 19 November 2017 at 04:57:11 UTC, Tony wrote:

 On Saturday, 18 November 2017 at 19:22:25 UTC, Meta wrote:

 On Saturday, 18 November 2017 at 16:21:30 UTC, Eljay wrote:

 [...]


 Don't worry, you've got a few years yet. Currently `body`is 
 not even deprecated; it's become a conditional keyword, or you 
 can use `do` in its place.


 It may be deprecated, but someone completely removed it from 
 the documentation on contracts. That could cause some confusion 
 for people using older versions of the compiler.

 https://dlang.org/spec/contracts.html


That's what the docarchives are for: 
https://docarchives.dlang.io/v2.074.0/spec/contracts.html
Nov 18 2017
parent reply Tony <tonytdominguez aol.com> writes:
On Sunday, 19 November 2017 at 07:21:32 UTC, Seb wrote:

 On Sunday, 19 November 2017 at 04:57:11 UTC, Tony wrote:

 On Saturday, 18 November 2017 at 19:22:25 UTC, Meta wrote:

 On Saturday, 18 November 2017 at 16:21:30 UTC, Eljay wrote:

 [...]


 Don't worry, you've got a few years yet. Currently `body`is 
 not even deprecated; it's become a conditional keyword, or 
 you can use `do` in its place.


 It may be deprecated, but someone completely removed it from 
 the documentation on contracts. That could cause some 
 confusion for people using older versions of the compiler.

 https://dlang.org/spec/contracts.html


 That's what the docarchives are for: 
 https://docarchives.dlang.io/v2.074.0/spec/contracts.html


OK, but how would someone who is looking at:

https://docarchives.dlang.io/v2.074.0/spec/contracts.html

know what version of the compiler it applies to and where to find 
older documentation for their version of the compiler?
Nov 19 2017
parent reply Tony <tonytdominguez aol.com> writes:
On Sunday, 19 November 2017 at 08:05:38 UTC, Tony wrote:

 OK, but how would someone who is looking at:

 https://docarchives.dlang.io/v2.074.0/spec/contracts.html


I wish this board had an edit function. That should be

"OK, but how would someone who is looking at:

https://dlang.org/spec/contracts.html
Nov 19 2017
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 19 November 2017 at 08:13:32 UTC, Tony wrote:

 On Sunday, 19 November 2017 at 08:05:38 UTC, Tony wrote:

 OK, but how would someone who is looking at:

 https://docarchives.dlang.io/v2.074.0/spec/contracts.html


 I wish this board had an edit function. That should be

 "OK, but how would someone who is looking at:

 https://dlang.org/spec/contracts.html


They wouldn't need to know. Obviously they know its purpose and 
how it works if they have it in their source code, if they don't 
have it in their source code and they look at contracts, then 
they will be fine either way as it's not a required keyword 
anymore and thus doesn't require documentation, since you can 
achieve the same semantics without using the keyword.

The keyword is completely irrelevant unless you're maintaining 
old source codes, in which case you should already be aware of 
how it functions and if you aren't then a little research won't 
hurt.
Nov 19 2017
next sibling parent reply Tony <tonytdominguez aol.com> writes:
On Sunday, 19 November 2017 at 11:02:37 UTC, bauss wrote:

 On Sunday, 19 November 2017 at 08:13:32 UTC, Tony wrote:

 On Sunday, 19 November 2017 at 08:05:38 UTC, Tony wrote:

 OK, but how would someone who is looking at:

 https://docarchives.dlang.io/v2.074.0/spec/contracts.html


 I wish this board had an edit function. That should be

 "OK, but how would someone who is looking at:

 https://dlang.org/spec/contracts.html


 They wouldn't need to know. Obviously they know its purpose and 
 how it works if they have it in their source code, if they 
 don't have it in their source code and they look at contracts, 
 then they will be fine either way


They won't be fine either way if they are using LDC or GDC right 
now or they are using a slightly older version of DMD and they 
want to try using contracts. They will look at the documentation 
and think that they need to write "do" and their version of the 
compiler will only accept "body", which won't be documented.


 as it's not a required keyword anymore and thus doesn't require 
 documentation, since you can achieve the same semantics without 
 using the keyword.

 The keyword is completely irrelevant unless you're maintaining 
 old source codes, in which case you should already be aware of 
 how it functions and if you aren't then a little research won't 
 hurt.


"do" doesn't appear to be optional and the compiler still talks 
about the deprecated "body", even if any mention of it has been 
removed from the documentation:

import std.stdio : writeln;

int MyFunction(int input)
in
{
    assert(input >= 0);
}
out (result)
{
    assert(result > 100);
}

{
    return input + 100;
}


void main()
{
    writeln("output: ",MyFunction(10));
}



dmd --version
DMD64 D Compiler v2.077.0
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright

dmd test_contracts.d
test_contracts.d(13): Error: missing `body { ... }` after `in` or 
`out`
Nov 19 2017
parent Nick Treleaven <nick geany.org> writes:
On Sunday, 19 November 2017 at 11:54:04 UTC, Tony wrote:

 dmd --version
 DMD64 D Compiler v2.077.0
 Copyright (c) 1999-2017 by Digital Mars written by Walter Bright

 dmd test_contracts.d
 test_contracts.d(13): Error: missing `body { ... }` after `in` 
 or `out`


Just made a pull to fix this:
https://github.com/dlang/dmd/pull/7347
Nov 21 2017
prev sibling parent Tony <tonytdominguez aol.com> writes:
On Sunday, 19 November 2017 at 11:02:37 UTC, bauss wrote:


 They wouldn't need to know. Obviously they know its purpose and 
 how it works if they have it in their source code, if they 
 don't have it in their source code and they look at contracts, 
 then they will be fine either way as it's not a required 
 keyword anymore and thus doesn't require documentation, since 
 you can achieve the same semantics without using the keyword.

 The keyword is completely irrelevant unless you're maintaining 
 old source codes, in which case you should already be aware of 
 how it functions and if you aren't then a little research won't 
 hurt.


I may have misunderstood you. I assumed you were saying that the 
"do" keyword was optional in the syntax. If not, given the fact 
that "body" may be required on the compiler that someone is 
currently using and the documentation only mentions "do", the 
keyword seems relevant to me.
Nov 19 2017
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 18 November 2017 at 19:22:25 UTC, Meta wrote:

 On Saturday, 18 November 2017 at 16:21:30 UTC, Eljay wrote:

 On Monday, 28 March 2011 at 18:59:03 UTC, Walter Bright wrote:

 On 3/27/2011 10:35 PM, Jonathan M Davis wrote:

 I'll be _very_ excited to have both the destructor issues 
 and the const issues
 sorted out. They are some of the more annoying quality of 
 implementation
 issues at the moment.


 Yes, I agree those are the top priority at the moment, now 
 that we have the 64 bit compiler online and the worst of the 
 optlink issues resolved.


 NECRO ALERT...

 But I just saw that 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md was 
 addressed with https://github.com/dlang/dmd/pull/6855 .

 I, for one, will miss 'body' the keyword.  Now I'll have to 
 update all my toy code.

 (Just kidding, I don't mind updating my toy code.  At least it 
 isn't a codebase the size of Photoshop!)


 Don't worry, you've got a few years yet. Currently `body`is not 
 even deprecated; it's become a conditional keyword, or you can 
 use `do` in its place.


Yeah, "no worries" but for example a few weeks ago a bug report 
has drawn my attention:

https://issues.dlang.org/show_bug.cgi?id=17925

After testing some code with i've indeed observed that the 
transition period for `do` had started...

"since when ?" i've wondered.

Good question, it's even not in the changelog:

https://www.google.fr/search?domains=dlang.org&dcr=0&biw=1280&bih=635&tbs=qdr%3Ay&ei=H34RWpKDPIzTgAatnqK4DA&q=body+do+site%3Adlang.org%2Fchangelog&oq=body+do+site%3Adlang.org%2Fchangelog&gs_l=psy-ab.3...4014.4428.0.4779.3.3.0.0.0.0.67.190.3.3.0....0...1.1.64.psy-ab..0.0.0....0.AOIgJDEhh_g

So maybe it's wort mentioning something like

"(formerly body, which is still allowed during ....)", because 
there's been a communication problem with that deprecation.
Nov 19 2017
next sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 19 November 2017 at 12:54:37 UTC, Basile B. wrote:

 Yeah, "no worries" but for example a few weeks ago a bug report 
 has drawn my attention:

 https://issues.dlang.org/show_bug.cgi?id=17925

 After testing some code with i've indeed observed that the 
 transition period for `do` had started...

 "since when ?" i've wondered.

 Good question, it's even not in the changelog:

 https://www.google.fr/search?domains=dlang.org&dcr=0&biw=1280&bih=635&tbs=qdr%3Ay&ei=H34RWpKDPIzTgAatnqK4DA&q=body+do+site%3Adlang.org%2Fchangelog&oq=body+do+site%3Adlang.org%2Fchangelog&gs_l=psy-ab.3...4014.4428.0.4779.3.3.0.0.0.0.67.190.3.3.0....0...1.1.64.psy-ab..0.0.0....0.AOIgJDEhh_g

 So maybe it's wort mentioning something like

 "(formerly body, which is still allowed during ....)", because 
 there's been a communication problem with that deprecation.


Yes, I'm pretty sure I created the PR to remove all references to 
`body` myself. It's part of the process; the first step is 
removing it from the documentation, because outright deprecation 
is too sudden. It's still perfectly usable, but we don't want to 
advertise it anymore.
Nov 19 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, November 19, 2017 21:07:53 Meta via Digitalmars-d wrote:

 On Sunday, 19 November 2017 at 12:54:37 UTC, Basile B. wrote:

 Yeah, "no worries" but for example a few weeks ago a bug report
 has drawn my attention:

 https://issues.dlang.org/show_bug.cgi?id=17925

 After testing some code with i've indeed observed that the
 transition period for `do` had started...

 "since when ?" i've wondered.

 Good question, it's even not in the changelog:

 https://www.google.fr/search?domains=dlang.org&dcr=0&biw=1280&bih=635&tb
 s=qdr%3Ay&ei=H34RWpKDPIzTgAatnqK4DA&q=body+do+site%3Adlang.org%2Fchangel
 og&oq=body+do+site%3Adlang.org%2Fchangelog&gs_l=psy-ab.3...4014.4428.0.4
 779.3.3.0.0.0.0.67.190.3.3.0....0...1.1.64.psy-ab..0.0.0....0.AOIgJDEhh_
 g

 So maybe it's wort mentioning something like

 "(formerly body, which is still allowed during ....)", because
 there's been a communication problem with that deprecation.


 Yes, I'm pretty sure I created the PR to remove all references to
 `body` myself. It's part of the process; the first step is
 removing it from the documentation, because outright deprecation
 is too sudden. It's still perfectly usable, but we don't want to
 advertise it anymore.


It would have been better to explain in the documentation that body was
being phased out rather than just removing it right when the changes were
made to dmd. It's already caused problems due to folks trying to use do and
it not working with the compiler that they're using (e.g. ldc).

https://stackoverflow.com/questions/46860573/do-ldc-and-gdc-support-d-language-contracts

- Jonathan M Davis
Nov 19 2017
parent Meta <jared771 gmail.com> writes:
On Sunday, 19 November 2017 at 21:14:58 UTC, Jonathan M Davis 
wrote:

 It would have been better to explain in the documentation that 
 body was being phased out rather than just removing it right 
 when the changes were made to dmd. It's already caused problems 
 due to folks trying to use do and it not working with the 
 compiler that they're using (e.g. ldc).

 https://stackoverflow.com/questions/46860573/do-ldc-and-gdc-support-d-language-contracts

 - Jonathan M Davis


Yeah, you're right. I never use GDC/LDC so I didn't consider them.
Nov 19 2017
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 19 November 2017 at 12:54:37 UTC, Basile B. wrote:

 Good question, it's even not in the changelog:

 https://www.google.fr/search?domains=dlang.org&dcr=0&biw=1280&bih=635&tbs=qdr%3Ay&ei=H34RWpKDPIzTgAatnqK4DA&q=body+do+site%3Adlang.org%2Fchangelog&oq=body+do+site%3Adlang.org%2Fchangelog&gs_l=psy-ab.3...4014.4428.0.4779.3.3.0.0.0.0.67.190.3.3.0....0...1.1.64.psy-ab..0.0.0....0.AOIgJDEhh_g

 So maybe it's wort mentioning something like

 "(formerly body, which is still allowed during ....)", because 
 there's been a communication problem with that deprecation.


Yes, I just checked and it's nowhere to be found in the 
changelog. Walter created the PR to implement the `do` syntax but 
he did not make a corresponding doc change. I'm not sure what to 
do considering 2.077.0 has already released.
Nov 19 2017
parent Basile B. <b2.temp gmx.com> writes:
On Sunday, 19 November 2017 at 21:19:58 UTC, Meta wrote:

 On Sunday, 19 November 2017 at 12:54:37 UTC, Basile B. wrote:

 Good question, it's even not in the changelog:

 https://www.google.fr/search?domains=dlang.org&dcr=0&biw=1280&bih=635&tbs=qdr%3Ay&ei=H34RWpKDPIzTgAatnqK4DA&q=body+do+site%3Adlang.org%2Fchangelog&oq=body+do+site%3Adlang.org%2Fchangelog&gs_l=psy-ab.3...4014.4428.0.4779.3.3.0.0.0.0.67.190.3.3.0....0...1.1.64.psy-ab..0.0.0....0.AOIgJDEhh_g

 So maybe it's wort mentioning something like

 "(formerly body, which is still allowed during ....)", because 
 there's been a communication problem with that deprecation.


 Yes, I just checked and it's nowhere to be found in the 
 changelog. Walter created the PR to implement the `do` syntax 
 but he did not make a corresponding doc change. I'm not sure 
 what to do considering 2.077.0 has already released.


It's probably too late for the changelog but the specs can still 
mention that there was another keyword in the past. New comers 
will encounter body much when they read old code.
Nov 19 2017
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/19/2017 04:54 AM, Basile B. wrote:


 After testing some code with i've indeed observed that the transition
 period for `do` had started...

 "since when ?" i've wondered.

 Good question, it's even not in the changelog:


Same here! I learned about this in a D snippet in an article on contract 
programming that I saw on Reddit:

 
https://www.reddit.com/r/programming/comments/7fxz1v/introduction_to_contract_programming/

void foo()
in {
     // ...
}
out {
     // ...
}
do {                         // <-- Looks good
     // ...
}

void main() {
     auto body = "repair";    // <-- WOO HOO! :)
}

Ali
Nov 27 2017