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 <d...@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 >