Names with trailing question mark

[Gor Gyolchanyan]

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
>