Clarifications for name lookup in classes

[jonmeow]

Summary of issue:

In classes:

1. Should unqualified name lookup be allowed for non-instance type members? In other words, presumably me.x is required, but does Create() to call one member from another?
2. Should instances be usable to access type members? In other words, should me.Create() work?

Details:

1. Unqualified name lookup

#472 mentions unqualified name lookup, but doesn't appear to address the question ("We didn't reach a conclusion between (1) and (2) here"). #875 doesn't clearly address it.

For example:

class Point {
  fn Create(x: i32, y: i32) -> Point;
  fn CreateOrigin() -> Point;
}

fn Point.CreateOrigin() {
  // Is this valid?
  return Create(0, 0);
}

2. Type member access through instance

class IntList {
  alias IteratorType = IntListIterator;
  fn Iterate[me: Self]() -> IteratorType;
}

fn IntList.Iterate[me: Self]() -> IteratorType {
  // Does this `IteratorType` access work?
  return me.IteratorType(me);
}

fn SideFunction() {
  var x: IntList = {}
  // Similarly, this access.
  x.IteratorType()
}

Note, an alternative here would be to require writing something like typeof(me).IteratorType or typeof(x).IteratorType, requiring stronger explicitness. I think the leads may have a planned answer for this though so I won't dig in.

Any other information that you want to share?

No response

[josh11b]

For 1, my understanding is that member functions are considered to be inside the class' scope even if they are defined out of line. This means that Create is in scope inside CreateOrigin.

For 2, I believe me.Create() is allowed, and I thought that was covered by #989 .

[jonmeow]

Thanks, it looks like #989 covered these cases and we're just missing a link as reminder.

[jonmeow]

Nevermind, I had misread member_access.md as covering name lookup within classes but it doesn't. It's still a question to leads to ensure the path they want.

[jonmeow]

On second thought, I've switched #2287 to a proposal to try to just resolve this in one go.