Names with trailing question mark

[Gor Gyolchanyan]

>   auto mts.empty ? "wonderful" : "awful";
>   auto mts.empty ? "awesome";

sorry, a typo:

   auto a0 = mts.empty ? "wonderful" : "awful";
   auto a1 = 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 = T.init)
   {
       if(array.length == 0)
           return yes;
       else
           return no;
   }
}

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

On Tue, Oct 4, 2011 at 2:22 PM, Gor Gyolchanyan
<gor.f.gyolchanyan at gmail.com> 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?
>
> On Tue, Oct 4, 2011 at 12:48 PM, Jacob Carlborg <doob at 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
>>
>