Ticket #140 (new defect)

Opened 1 year ago

Last modified 9 months ago

Allow operator names as identifiers in namespace-qualified names

Reported by: lth Assigned to: jeffdyer
Type: defect Priority: major
Milestone: Component: RefImpl
Version: 4 Keywords:
Cc: jeffdyer, graydon

Description

The operator overloading proposal says that operator::=== is the way to talk about the function defined by operator overloading on a class (for a bunch of operator names).

Various other proposals use intrinsic::=== as the syntax to access primitive meanings of operators in the language.

I would also like to introduce syntax like int.intrinsic::+ to talk about type-specific operations in the language but that's still open.

These are rejected by the parser now.

I don't know whether intrinsic::=== and intrinsic::"===" are two different names or the same name. I'm guessing the latter.

Attachments

Change History

Changed 1 year ago by lth

  • cc set to jeffdyer

Jeff, we need some movement here.

At a minimum, we need to clarify whether:

  • the names we allow are in fact intrinsic::=== and so on
  • operator names can be used following any namespace name, not just intrinsic
  • intrinsic::=== is the same as intrinsic::["==="]

(I no longer think there is a need for eg int.intrinsic::+ and so on.)

Changed 1 year ago by jeffdyer

The grammar allows for all these forms of qualified names, including int.intrinsic:+. The meaning of intrinsic::=== should be the same as that of intrinsic::["==="], in my opinion.

If we agree that the grammar is correct, then this is a refimpl bug.

Jd

Changed 1 year ago by lth

  • cc changed from jeffdyer to jeffdyer, graydon
  • component changed from Spec to RefImpl

I think the grammar is correct.

The RI doesn't understand it, so yes, RI bug (presumably parser bug).

Changed 9 months ago by lth

Probably not urgent any more since we're probably not adopting operator overloading. Let's hold off.

Note: See TracTickets for help on using tickets.