http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #40 from monarchdodra@gmail.com 2013-03-22 09:05:10 PDT ---
(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.

//Convenience to transform a pointer into a slice:
size_t opDollar(T)(T* p)
{
    return 1;
}
...
void main()
{
    int   i = 1;
    int*  p = &i;
    int[] s = p[0 .. $]; //Now legal!
}

So allowing opDollar as non-member operator could be used unsafely just the same as any other operator.

> I don't think it
> would be inconsistent to allow UFCS opDollar and not allow other operators via
> UFCS.

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?

There will always be stupid users to do stupid things with code. I don't see why it should prevent us from having useful and smart tools.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #41 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-03-22 09:23:48 PDT ---
(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.

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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #42 from monarchdodra@gmail.com 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #43 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-03-22 14:56:19 PDT ---
I think that being able to do something like overload + for strings would be very bad (which having UFCS work with overloaded operators would allow), and the fact that there would be no way to differentiate between functions when overloaded operators which used UFCS conflicted just makes it worse.

But opDollar is quite different from other operators (it's really not any different from overloading any function with a particular name, since it's quite restricted it what it's used for), so maybe it's okay for it. I'd be quite opposed to allowing it in general though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #44 from Andrei Alexandrescu <andrei@erdani.com> 2013-03-24 08:24:46 PDT ---
I gave this long thread a read and reached a decision. Sorry for the dictatorial approach but this seems to be a matter in which reasonable people may disagree so at some point we need to just choose a way and stick with it. Among my priorities in choosing a behavior is that of simplicity - we can't require people to mind a trait such as supportsOpDollar, or require them to define an alias for opDollar in casual ranges.

So, there are a few cases to look at. Given a type T:

1. hasLength!T || isNarrowString!T, but T does not define a member opDollar.

Then ALL uses of expr.$ in indexing expressions involving values of type T will automatically alias themselves to expr.length. This includes UFCS, i.e. if user code defines a module-level property length(T), then expr.$ lowers into expr.length which in turn may lower to length(expr).

(Note that hasLength!T currently does work with UFCS.)

2. T defines opDollar.

Great - nothing to do, it's all explicit.

3. expr.length has no meaning and T does not define opDollar.

In this case there is a compile-time error.

===========

Regarding having opDollar and/or other operators work as UCSF, this would be desirable from a completeness/expectability/consistency standpoint. I don't quite buy the argument that that opens a can of worms. However, seeing as there's already a compiler change for that, I suggest we go this least-committal route for now and defer that decision for later.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #45 from Andrei Alexandrescu <andrei@erdani.com> 2013-03-24 08:26:27 PDT ---
s/UCSF/UFCS/

University of California San Francisco for the win!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #46 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-03-24 12:55:40 PDT ---
(In reply to comment #44)
> 1. hasLength!T || isNarrowString!T, but T does not define a member opDollar.

this can be shortened to hasLength!T, all strings define $, they are arrays. The compiler shouldn't be trying to guess whether something is a narrow string or not according to phobos (or maybe I read this too literally?)

The rest of this is not unreasonable, and aside from breaking current code (albeit less common current code in a non-obvious way), this proposal misses one situation:  you want to define .length, but NOT opDollar.  In this case, @disable opDollar should be allowed (if it's not already) as monarchdodra suggested.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #47 from Andrei Alexandrescu <andrei@erdani.com> 2013-03-24 13:08:46 PDT ---
(In reply to comment #46)
> (In reply to comment #44)
> > 1. hasLength!T || isNarrowString!T, but T does not define a member opDollar.
> 
> this can be shortened to hasLength!T, all strings define $, they are arrays. The compiler shouldn't be trying to guess whether something is a narrow string or not according to phobos (or maybe I read this too literally?)

Good point, thanks.

> The rest of this is not unreasonable, and aside from breaking current code (albeit less common current code in a non-obvious way), this proposal misses one situation:  you want to define .length, but NOT opDollar.  In this case, @disable opDollar should be allowed (if it's not already) as monarchdodra suggested.

Yah, I was thinking of private or @disable'd symbols as "defined". Good to clarify that.

@Kenji, shall we go for this?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #48 from monarchdodra@gmail.com 2013-03-24 13:47:32 PDT ---
(In reply to comment #47)
> (In reply to comment #46)
> > (In reply to comment #44)
> > > 1. hasLength!T || isNarrowString!T, but T does not define a member opDollar.
> > 
> > this can be shortened to hasLength!T, all strings define $, they are arrays. The compiler shouldn't be trying to guess whether something is a narrow string or not according to phobos (or maybe I read this too literally?)
> 
> Good point, thanks.
> 
> > The rest of this is not unreasonable, and aside from breaking current code (albeit less common current code in a non-obvious way), this proposal misses one situation:  you want to define .length, but NOT opDollar.  In this case, @disable opDollar should be allowed (if it's not already) as monarchdodra suggested.
> 
> Yah, I was thinking of private or @disable'd symbols as "defined". Good to clarify that.
> 
> @Kenji, shall we go for this?

I apologize, but this isn't clear to me. I understand the what/why of the goal, but I don't understand the how? Is it the compiler that is translating $ to length? Then if so, how does "hasLength!T" come into play?

Or are we doing this "via" the compiler as a workaround until we can implement opDollar as non-member? (since you mentioned the possibility of allowing non-member operators)

I'm sorry, I just want to fully understand which direction we are taking.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #49 from Andrei Alexandrescu <andrei@erdani.com> 2013-03-24 14:51:44 PDT ---
> I apologize, but this isn't clear to me. I understand the what/why of the goal, but I don't understand the how? Is it the compiler that is translating $ to length?

Yes.

>Then if so, how does "hasLength!T" come into play?

Whenever I wrote "hasLength!T" I meant "The expression (expr).length exists for
expr of type T".

> Or are we doing this "via" the compiler as a workaround until we can implement opDollar as non-member? (since you mentioned the possibility of allowing non-member operators)

I'm thinking of putting this decision in the compiler for now, it's the least committal change.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------