www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Names with trailing question mark

reply bearophile <bearophileHUGS lycos.com> writes:
Predicates are quite common. In D I presume the standard way to write them is
with a name like "isFoo". In other languages they are written in other ways:


if (foo.isEven) {}
if (foo.isEven()) {}
filter!isEven(data)

if (foo.evenQ) {}
if (foo.evenQ()) {}
filter!evenQ(data)

if (foo.even?) {}
if (foo.even?()) {}
filter!even?(data)

Other usages:

contains?
areInside ==> inside?


I don't remember serious recent discussions here about that last form. Allowing
a single trailing question mark in D names has some advantages:

1) It gives a standard way to denote a predicate, so it becomes very easy to
tell apart a predicate from other non predicate things.

2) It allows for short names.

3) A single question mark is easy and quick to write on most keyboards.

4) It is used in other languages, as Ruby, and people seem to appreciate it.

5) Its meaning is probably easy enough to understand and remember.



Some disadvantages:
1) "?" makes code less easy to read aloud.

2) It is less good to use the trailing "?" in functions that aren't properties,
the syntax becomes less nice looking:
if (foo.even()?)

3) The usage of the trailing "?" in names forbids later different usages for
it, like denoting nullable types.

4) In expressions that use the ternary operator and a property predicate
(without leading ()) it becomes a bit less easy to read (example from
http://stackoverflow.com):

string customerName = user.loggedIn? ? user.name : "Who are you?";

I think this too gets accepted:
string customerName = user.loggedIn??user.name:"Who are you?";

I vaguely like the idea of using a trailing question mark in predicate names.

Bye,
bearophile
Oct 03 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:j6dgvp$1rot$1 digitalmars.com...

 Predicates are quite common. In D I presume the standard way to write them 
 is with a name like "isFoo". In other languages they are written in other 
 ways:


 if (foo.isEven) {}
 if (foo.isEven()) {}
 filter!isEven(data)

 if (foo.evenQ) {}
 if (foo.evenQ()) {}
 filter!evenQ(data)

 if (foo.even?) {}
 if (foo.even?()) {}
 filter!even?(data)

 Other usages:

 contains?
 areInside ==> inside?


It's nice, and it's one of the things in Ruby that I like, but I'd be 
surprised if it didn't cause parsing (or even lexing) ambiguities with ?:. 
If that could be reasonably solved, I'd be in favor of it, but I'm not sure 
it can.
Oct 03 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-10-04 03:13, Nick Sabalausky wrote:

 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:j6dgvp$1rot$1 digitalmars.com...

 Predicates are quite common. In D I presume the standard way to write them
 is with a name like "isFoo". In other languages they are written in other
 ways:


 if (foo.isEven) {}
 if (foo.isEven()) {}
 filter!isEven(data)

 if (foo.evenQ) {}
 if (foo.evenQ()) {}
 filter!evenQ(data)

 if (foo.even?) {}
 if (foo.even?()) {}
 filter!even?(data)

 Other usages:

 contains?
 areInside ==>  inside?


 It's nice, and it's one of the things in Ruby that I like, but I'd be
 surprised if it didn't cause parsing (or even lexing) ambiguities with ?:.
 If that could be reasonably solved, I'd be in favor of it, but I'm not sure
 it can.


If would choose to require a space before the question mark in a ternary 
operator.

-- 
/Jacob Carlborg
Oct 03 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-04 01:37, bearophile wrote:

 Predicates are quite common. In D I presume the standard way to write them is
with a name like "isFoo". In other languages they are written in other ways:


 if (foo.isEven) {}
 if (foo.isEven()) {}
 filter!isEven(data)

 if (foo.evenQ) {}
 if (foo.evenQ()) {}
 filter!evenQ(data)

 if (foo.even?) {}
 if (foo.even?()) {}
 filter!even?(data)

 Other usages:

 contains?
 areInside ==>  inside?


 I don't remember serious recent discussions here about that last form.
Allowing a single trailing question mark in D names has some advantages:

 1) It gives a standard way to denote a predicate, so it becomes very easy to
tell apart a predicate from other non predicate things.

 2) It allows for short names.

 3) A single question mark is easy and quick to write on most keyboards.

 4) It is used in other languages, as Ruby, and people seem to appreciate it.

 5) Its meaning is probably easy enough to understand and remember.



 Some disadvantages:
 1) "?" makes code less easy to read aloud.

 2) It is less good to use the trailing "?" in functions that aren't
properties, the syntax becomes less nice looking:
 if (foo.even()?)


Why would you put the question mark after the parentheses. At least in 
Ruby the question mark is part of the method name. This looks better:

if (foo.even?())



 3) The usage of the trailing "?" in names forbids later different usages for
it, like denoting nullable types.

 4) In expressions that use the ternary operator and a property predicate
(without leading ()) it becomes a bit less easy to read (example from
http://stackoverflow.com):

 string customerName = user.loggedIn? ? user.name : "Who are you?";

 I think this too gets accepted:
 string customerName = user.loggedIn??user.name:"Who are you?";


This is not accepted in Ruby. You need a space after the second question 
mark. If this would be implemented I would vote for requiring a space 
after the first question mark as well.


 I vaguely like the idea of using a trailing question mark in predicate names.

 Bye,
 bearophile


What about allowing method names like Scala does, containing arbitrary 
symbols.

void ::: (int a) {}

I assume that will complicate the language quite a lot.

-- 
/Jacob Carlborg
Oct 03 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 if (foo.even()?)


 
 Why would you put the question mark after the parentheses. At least in 
 Ruby the question mark is part of the method name. This looks better:
 
 if (foo.even?())


It's a typo of mine, sorry :-) The question mark is part of the name, so it is
of course before the ().



 I think this too gets accepted:
 string customerName = user.loggedIn??user.name:"Who are you?";


 
 This is not accepted in Ruby. You need a space after the second question 
 mark. If this would be implemented I would vote for requiring a space 
 after the first question mark as well.


In D the space after the second question mark is not required, and I think you
can't change this rule unless you want to change lot of already written D code.
So I think this is not a good idea.

Regarding the idea of requiring a space after the first question mark, it is
doable, even if a bit unusual. I have mixed feelings about it. Maybe other
people will express what they think about it.



 What about allowing method names like Scala does, containing arbitrary 
 symbols.
 
 void ::: (int a) {}
 
 I assume that will complicate the language quite a lot.


This is a change far bigger than the one I have suggested (that in most cases
is limited to allowing one specific extra trailing symbol in names of
functions/methods). Yours is an interesting idea, but it introduces
complexities and opportunities that are larger and very different from the
topic of this thread. So if you want to discuss your idea, its pro and cons, I
suggest you to do it in a different new thread.


I have also thought about the idea of accepting the "?" as leading symbol only
for function/method names that return a single boolean value. This sounds cute
(because it makes this design more focused), but D has templates so there is
also code like:

T foo?(T)(T x) { return x; }

I guess it's not a good idea to statically enforce T to be a boolean...

Bye and thank you,
bearophile
Oct 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-04 10:28, bearophile wrote:

 Jacob Carlborg:


 if (foo.even()?)


 Why would you put the question mark after the parentheses. At least in
 Ruby the question mark is part of the method name. This looks better:

 if (foo.even?())


 It's a typo of mine, sorry :-) The question mark is part of the name, so it is
of course before the ().


Hehe, no problem.


 I think this too gets accepted:
 string customerName = user.loggedIn??user.name:"Who are you?";


 This is not accepted in Ruby. You need a space after the second question
 mark. If this would be implemented I would vote for requiring a space
 after the first question mark as well.


 In D the space after the second question mark is not required, and I think you
can't change this rule unless you want to change lot of already written D code.
So I think this is not a good idea.


In D you cannot have two question marks like that after each other (I 
assume). So this doesn't matter.


 Regarding the idea of requiring a space after the first question mark, it is
doable, even if a bit unusual. I have mixed feelings about it. Maybe other
people will express what they think about it.


Is it unusual? How may people are actually writing like this:

foo?a:b

I have not problem breaking the code above. When a method name can end 
with a question mark it's even more important to not write like this. I 
always write like this:

foo ? a : b


 What about allowing method names like Scala does, containing arbitrary
 symbols.

 void ::: (int a) {}

 I assume that will complicate the language quite a lot.


 This is a change far bigger than the one I have suggested (that in most cases
is limited to allowing one specific extra trailing symbol in names of
functions/methods). Yours is an interesting idea, but it introduces
complexities and opportunities that are larger and very different from the
topic of this thread. So if you want to discuss your idea, its pro and cons, I
suggest you to do it in a different new thread.


It just an idea that would be nice to have. But as you say it's too big 
of a change and I'm pretty certain it won't go anywhere.


 I have also thought about the idea of accepting the "?" as leading symbol only
for function/method names that return a single boolean value. This sounds cute
(because it makes this design more focused), but D has templates so there is
also code like:

 T foo?(T)(T x) { return x; }

 I guess it's not a good idea to statically enforce T to be a boolean...

 Bye and thank you,
 bearophile



-- 
/Jacob Carlborg
Oct 04 2011
next sibling parent reply travert phare.normalesup.org (Christophe) writes:
I don't really like this idea. D has limitations to accepted symbol that 
are strict, but handy in many cases. Accepting strange character in a 
method name can lead to parsing ambiguities and I like the way D enforce 
non-ambiguous code. I understand why we can think that the question mark 
is nicer than an auxilliary in this case, but where to draw the line? 
The question mark already lead to a (small) parsing ambiguity.
Oct 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-04 12:12, Christophe wrote:

 I don't really like this idea. D has limitations to accepted symbol that
 are strict, but handy in many cases. Accepting strange character in a
 method name can lead to parsing ambiguities and I like the way D enforce
 non-ambiguous code. I understand why we can think that the question mark
 is nicer than an auxilliary in this case, but where to draw the line?
 The question mark already lead to a (small) parsing ambiguity.


Yeah, that's what I was thinking. If we allow "name?" should we allow 
"name!" as well (as Ruby does). Is there anything else we should allow? 
Allow everything?

I was thinking something like that.

-- 
/Jacob Carlborg
Oct 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-10-04 16:03, Jacob Carlborg wrote:

 On 2011-10-04 12:12, Christophe wrote:

 I don't really like this idea. D has limitations to accepted symbol that
 are strict, but handy in many cases. Accepting strange character in a
 method name can lead to parsing ambiguities and I like the way D enforce
 non-ambiguous code. I understand why we can think that the question mark
 is nicer than an auxilliary in this case, but where to draw the line?
 The question mark already lead to a (small) parsing ambiguity.


 Yeah, that's what I was thinking. If we allow "name?" should we allow
 "name!" as well (as Ruby does). Is there anything else we should allow?
 Allow everything?

 I was thinking something like that.


Just realized I thought this post was in a different thread.

-- 
/Jacob Carlborg
Oct 04 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
   auto mts.empty ? "wonderful" : "awful";
   auto mts.empty ? "awesome";


sorry, a typo:

   auto a0 =3D mts.empty ? "wonderful" : "awful";
   auto a1 =3D mts.empty ? "awesome";



struct MyTestStruct
{
   int[] array;

   // "this" as a template parameter will make the condition apply to
the class or struct itself.
value.
   T opCond(string name : "this", T)(lazy T yes, lazy T no =3D T.init)
   {
       if(array.length =3D=3D 0)
           return yes;
       else
           return no;
   }
}

unittest
{
    MyTestStruct mts;
    auto a =3D mts ? wonderful" : "awful";
}

On Tue, Oct 4, 2011 at 2:22 PM, Gor Gyolchanyan
<gor.f.gyolchanyan gmail.com> wrote:

 Here's what i suggest to do:

 struct MyTestStruct
 {
 =A0 =A0int[] array;

 =A0 =A0// opCond must take at least a single string template parameter
 and exactly two lazy parameters, second of which may have a default
 value.
 =A0 =A0T opCond(string name : "empty", T)(lazy T yes, lazy T no =3D T.ini=


t)

 =A0 =A0{
 =A0 =A0 =A0 =A0if(array.length =3D=3D 0)
 =A0 =A0 =A0 =A0 =A0 =A0return yes;
 =A0 =A0 =A0 =A0else
 =A0 =A0 =A0 =A0 =A0 =A0return no;
 =A0 =A0}
 }

 unittest
 {
 =A0 =A0MyTestStruct mts;
 =A0 =A0auto mts.empty ? "wonderful" : "awful";
 =A0 =A0auto mts.empty ? "awesome";
 }

 Allowing this will not break any existing code, since the effect and
 rules are essentially the same.
 How about this?

 On Tue, Oct 4, 2011 at 12:48 PM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-04 10:28, bearophile wrote:

 Jacob Carlborg:


 if (foo.even()?)


 Why would you put the question mark after the parentheses. At least in
 Ruby the question mark is part of the method name. This looks better:

 if (foo.even?())


 It's a typo of mine, sorry :-) The question mark is part of the name, s=






o

 it is of course before the ().


 Hehe, no problem.


 I think this too gets accepted:
 string customerName =3D user.loggedIn??user.name:"Who are you?";


 This is not accepted in Ruby. You need a space after the second questi=








on

 mark. If this would be implemented I would vote for requiring a space
 after the first question mark as well.


 In D the space after the second question mark is not required, and I th=






ink

 you can't change this rule unless you want to change lot of already wri=






tten

 D code. So I think this is not a good idea.


 In D you cannot have two question marks like that after each other (I
 assume). So this doesn't matter.


 Regarding the idea of requiring a space after the first question mark, =






it

 is doable, even if a bit unusual. I have mixed feelings about it. Maybe
 other people will express what they think about it.


 Is it unusual? How may people are actually writing like this:

 foo?a:b

 I have not problem breaking the code above. When a method name can end w=




ith

 a question mark it's even more important to not write like this. I alway=




s

 write like this:

 foo ? a : b


 What about allowing method names like Scala does, containing arbitrary
 symbols.

 void ::: (int a) {}

 I assume that will complicate the language quite a lot.


 This is a change far bigger than the one I have suggested (that in most
 cases is limited to allowing one specific extra trailing symbol in name=






s of

 functions/methods). Yours is an interesting idea, but it introduces
 complexities and opportunities that are larger and very different from =






the

 topic of this thread. So if you want to discuss your idea, its pro and =






cons,

 I suggest you to do it in a different new thread.


 It just an idea that would be nice to have. But as you say it's too big =




of a

 change and I'm pretty certain it won't go anywhere.


 I have also thought about the idea of accepting the "?" as leading symb=






ol

 only for function/method names that return a single boolean value. This
 sounds cute (because it makes this design more focused), but D has temp=






lates

 so there is also code like:

 T foo?(T)(T x) { return x; }

 I guess it's not a good idea to statically enforce T to be a boolean...

 Bye and thank you,
 bearophile



 --
 /Jacob Carlborg
Oct 04 2011
prev sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Here's what i suggest to do:

struct MyTestStruct
{
    int[] array;

    // opCond must take at least a single string template parameter
and exactly two lazy parameters, second of which may have a default
value.
    T opCond(string name : "empty", T)(lazy T yes, lazy T no = T.init)
    {
        if(array.length == 0)
            return yes;
        else
            return no;
    }
}

unittest
{
    MyTestStruct mts;
    auto mts.empty ? "wonderful" : "awful";
    auto mts.empty ? "awesome";
}

Allowing this will not break any existing code, since the effect and
rules are essentially the same.
How about this?

On Tue, Oct 4, 2011 at 12:48 PM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-04 10:28, bearophile wrote:

 Jacob Carlborg:


 if (foo.even()?)


 Why would you put the question mark after the parentheses. At least in
 Ruby the question mark is part of the method name. This looks better:

 if (foo.even?())


 It's a typo of mine, sorry :-) The question mark is part of the name, so
 it is of course before the ().


 Hehe, no problem.


 I think this too gets accepted:
 string customerName = user.loggedIn??user.name:"Who are you?";


 This is not accepted in Ruby. You need a space after the second question
 mark. If this would be implemented I would vote for requiring a space
 after the first question mark as well.


 In D the space after the second question mark is not required, and I think
 you can't change this rule unless you want to change lot of already written
 D code. So I think this is not a good idea.


 In D you cannot have two question marks like that after each other (I
 assume). So this doesn't matter.


 Regarding the idea of requiring a space after the first question mark, it
 is doable, even if a bit unusual. I have mixed feelings about it. Maybe
 other people will express what they think about it.


 Is it unusual? How may people are actually writing like this:

 foo?a:b

 I have not problem breaking the code above. When a method name can end with
 a question mark it's even more important to not write like this. I always
 write like this:

 foo ? a : b


 What about allowing method names like Scala does, containing arbitrary
 symbols.

 void ::: (int a) {}

 I assume that will complicate the language quite a lot.


 This is a change far bigger than the one I have suggested (that in most
 cases is limited to allowing one specific extra trailing symbol in names of
 functions/methods). Yours is an interesting idea, but it introduces
 complexities and opportunities that are larger and very different from the
 topic of this thread. So if you want to discuss your idea, its pro and cons,
 I suggest you to do it in a different new thread.


 It just an idea that would be nice to have. But as you say it's too big of a
 change and I'm pretty certain it won't go anywhere.


 I have also thought about the idea of accepting the "?" as leading symbol
 only for function/method names that return a single boolean value. This
 sounds cute (because it makes this design more focused), but D has templates
 so there is also code like:

 T foo?(T)(T x) { return x; }

 I guess it's not a good idea to statically enforce T to be a boolean...

 Bye and thank you,
 bearophile



 --
 /Jacob Carlborg
Oct 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-10-04 12:22, Gor Gyolchanyan wrote:

 Here's what i suggest to do:

 struct MyTestStruct
 {
      int[] array;

      // opCond must take at least a single string template parameter
 and exactly two lazy parameters, second of which may have a default
 value.
      T opCond(string name : "empty", T)(lazy T yes, lazy T no = T.init)
      {
          if(array.length == 0)
              return yes;
          else
              return no;
      }
 }

 unittest
 {
      MyTestStruct mts;
      auto mts.empty ? "wonderful" : "awful";
      auto mts.empty ? "awesome";
 }

 Allowing this will not break any existing code, since the effect and
 rules are essentially the same.
 How about this?


That seems more like overloading the ternary operator.

-- 
/Jacob Carlborg
Oct 04 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04.10.2011 01:37, bearophile wrote:

 Predicates are quite common. In D I presume the standard way to write them is
with a name like "isFoo". In other languages they are written in other ways:


 if (foo.isEven) {}
 if (foo.isEven()) {}
 filter!isEven(data)

 if (foo.evenQ) {}
 if (foo.evenQ()) {}
 filter!evenQ(data)

 if (foo.even?) {}
 if (foo.even?()) {}
 filter!even?(data)

 Other usages:

 contains?
 areInside ==>  inside?


 I don't remember serious recent discussions here about that last form.
Allowing a single trailing question mark in D names has some advantages:

 1) It gives a standard way to denote a predicate, so it becomes very easy to
tell apart a predicate from other non predicate things.

 2) It allows for short names.

 3) A single question mark is easy and quick to write on most keyboards.

 4) It is used in other languages, as Ruby, and people seem to appreciate it.

 5) Its meaning is probably easy enough to understand and remember.



 Some disadvantages:
 1) "?" makes code less easy to read aloud.

 2) It is less good to use the trailing "?" in functions that aren't
properties, the syntax becomes less nice looking:
 if (foo.even()?)

 3) The usage of the trailing "?" in names forbids later different usages for
it, like denoting nullable types.

 4) In expressions that use the ternary operator and a property predicate
(without leading ()) it becomes a bit less easy to read (example from
http://stackoverflow.com):

 string customerName = user.loggedIn? ? user.name : "Who are you?";

 I think this too gets accepted:
 string customerName = user.loggedIn??user.name:"Who are you?";

 I vaguely like the idea of using a trailing question mark in predicate names.

 Bye,
 bearophile


This would break lexer/parser separation and make the parsing of 
conditional expressions painfully complicated and ambiguous.

For example, how would you parse the following?

foo?+foo?(a):b;

it could be

foo ? (+foo?(a)) : b;

or

((foo?)+foo) ? (a) : b;


I'd like to have trailing ' in identifiers though, having them would not 
introduce ambiguities or break existing code.

immutable x=1;
immutable x'=x+2;
Oct 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-04 15:03, Timon Gehr wrote:

 On 04.10.2011 01:37, bearophile wrote:

 Predicates are quite common. In D I presume the standard way to write
 them is with a name like "isFoo". In other languages they are written
 in other ways:


 if (foo.isEven) {}
 if (foo.isEven()) {}
 filter!isEven(data)

 if (foo.evenQ) {}
 if (foo.evenQ()) {}
 filter!evenQ(data)

 if (foo.even?) {}
 if (foo.even?()) {}
 filter!even?(data)

 Other usages:

 contains?
 areInside ==> inside?


 I don't remember serious recent discussions here about that last form.
 Allowing a single trailing question mark in D names has some advantages:

 1) It gives a standard way to denote a predicate, so it becomes very
 easy to tell apart a predicate from other non predicate things.

 2) It allows for short names.

 3) A single question mark is easy and quick to write on most keyboards.

 4) It is used in other languages, as Ruby, and people seem to
 appreciate it.

 5) Its meaning is probably easy enough to understand and remember.



 Some disadvantages:
 1) "?" makes code less easy to read aloud.

 2) It is less good to use the trailing "?" in functions that aren't
 properties, the syntax becomes less nice looking:
 if (foo.even()?)

 3) The usage of the trailing "?" in names forbids later different
 usages for it, like denoting nullable types.

 4) In expressions that use the ternary operator and a property
 predicate (without leading ()) it becomes a bit less easy to read
 (example from http://stackoverflow.com):

 string customerName = user.loggedIn? ? user.name : "Who are you?";

 I think this too gets accepted:
 string customerName = user.loggedIn??user.name:"Who are you?";

 I vaguely like the idea of using a trailing question mark in predicate
 names.

 Bye,
 bearophile


 This would break lexer/parser separation and make the parsing of
 conditional expressions painfully complicated and ambiguous.

 For example, how would you parse the following?

 foo?+foo?(a):b;

 it could be

 foo ? (+foo?(a)) : b;

 or

 ((foo?)+foo) ? (a) : b;


I would say it would be illegal and that the ternary operator requires a 
space before the question mark. It works like this in Ruby as well. It 
would be parsed like this:

(foo?) + (foo?(a)) : b

Have a look at: http://d-programming-language.org/lex.html

"The source text is split into tokens using the maximal munch technique, 
i.e., the lexical analyzer tries to make the longest token it can."

"For example >> is a right shift token, not two greater than tokens."

It's the same here. Since "?" would be a legal symbol in a method name, 
"foo?" is the method name, not "foo" and "?".

-- 
/Jacob Carlborg
Oct 04 2011
parent travert phare.normalesup.org (Christophe) writes:
Jacob Carlborg , dans le message (digitalmars.D:146055), a écrit :

 
 I would say it would be illegal and that the ternary operator requires a 
 space before the question mark. It works like this in Ruby as well. It 
 would be parsed like this:
 
 (foo?) + (foo?(a)) : b
 
 Have a look at: http://d-programming-language.org/lex.html
 
 "The source text is split into tokens using the maximal munch technique, 
 i.e., the lexical analyzer tries to make the longest token it can."
 
 "For example >> is a right shift token, not two greater than tokens."
 
 It's the same here. Since "?" would be a legal symbol in a method name, 
 "foo?" is the method name, not "foo" and "?".


This behavior is consistent in itself, but it is not consistent with 
most common bracket langages that support ?: opperator.
That also means that you break half of the code that use ?:. You may 
think it is bad writing, but I like the ?: operator to be written like 
that: "a? b: c", and this has been legal for a long time now.
Oct 04 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
bearophile Wrote:


 contains?
 areInside ==> inside?
 
 
 I don't remember serious recent discussions here about that last form.
Allowing a single trailing question mark in D names has some advantages:
 
 1) It gives a standard way to denote a predicate, so it becomes very easy to
tell apart a predicate from other non predicate things.
 
 2) It allows for short names.
 
 3) A single question mark is easy and quick to write on most keyboards.
 
 4) It is used in other languages, as Ruby, and people seem to appreciate it.
 
 5) Its meaning is probably easy enough to understand and remember.


I don't think I like symbols in variable names. I'm not sure since I've never
used such, but the only time I like the symbols is by itself and performing an
operation.



There are probably many exceptions within Unicode, but if it is used by the
language I'll likely just be annoyed by it. Just my thought.
Oct 04 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
 I vaguely like the idea of using a trailing question mark in predicate names.


Thank you to all the people that have answered.

I don't like to write isFoo, I'd like to write foo?, but after the discussions
I presume this idea will not see the light in D :-|

Bye,
bearophile
Oct 05 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Read my thread about "thoughts on improving the operators".
Your idea might see the light after all :-)

On Wed, Oct 5, 2011 at 2:42 PM, bearophile <bearophileHUGS lycos.com> wrote:

 I vaguely like the idea of using a trailing question mark in predicate names.


 Thank you to all the people that have answered.

 I don't like to write isFoo, I'd like to write foo?, but after the discussions
I presume this idea will not see the light in D :-|

 Bye,
 bearophile
Oct 05 2011