http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #42 from [email protected] 2013-03-22 14:52:19 PDT --- (In reply to comment #41) > (In reply to comment #40) > > (In reply to comment #39) > > > However, we can probably make opDollar a special case, it's not really an > > > operator but a special symbol that $ gets translated into. > > > > By that logic, opBinary is not really an operator, but a special symbol "+" > > gets translated into. Besides, you could do very stupid stuff with opDollar > > the > > same as with any operator. > > It's most definitely not an operator, despite the name. It's a property. To > say opDollar is an operator is like saying length is an operator. You play on words. Both are not exclusive. It is an operator that is a property. BTW, is opUnary++ as operator? opUnary! ? In any case, I see no point in arguing over this particular point. > > So allowing opDollar as non-member operator could be used unsafely just the > > same as any other operator. > > You misunderstand, what I meant was because it's not technically an operator, > we could give it special permission to allow UFCS and technically be correct > saying we don't allow operator overloading with UFCS. I didn't say it would > always be safe! > > > I'm really just questioning why we don't allow UFCS for *all* operators? > > Seems > > like a restriction when you take into account the fact that you have UFCS. > > After all, it can already be used to give built-in types new attributes. Why > > are operators different from functions? > > I don't have a problem with it, I was suggesting we could allow it only for > opDollar as a compromise for those who feel operators shouldn't be UFCS-able. > > In fact, we already can add operators via type-wrapping and alias this. I > don't see the issue with allowing UFCS as a cleaner solution for that. I think we are on the same page. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
