Records, consts, and implicit data passing

@ghbrown: I'm just dropping by to say that I'm back from vacation now, appreciate @mppf picking up the conversation about sort design rationale and futures. It seems you have some dangling/implied questions there about potential futures which I don't feel expert enough in the Sort module to be able to comment on other than to say that I find the notion of an optional reverse boolean argument appealing from a user standpoint, from the perspective of making a common case simple. I'm ignoring any potential implementation/maintenance/performance costs in saying that, though. I agree with Michael's suggestion to kick off a "feature request" GitHub issue for that if you'd like to champion it (and that could be a more permanent place to discuss implications further as well).

Rewinding further, I'd like to be sure we capture a GitHub issue for the compiler permitting tertiary methods to be defined on variables rather than types. If you don't have the time/interest in filing that, let me know and I'll add it to my queue.

Like Michael, it's not immediately obvious to me what should happen with the ambiguity between the two tertiary methods. I'm fairly certain that if you were to simply insert a call to .key(), you'd see the ambiguity, and that the issue is that the Sort code doesn't simply call it, but asks whether it can call it where the ambiguity results in a "no" answer, causing it to fall back to its other approach. This relates to a common discussion topic with our reflection routines which is what they should do about errors. For example, imagine the following code sketch:

proc foo() {
  compilerError("Calling foo() is erroneous");
}

writeln(canResolve("foo"));

Should the behavior here be:

  • prints true: You can call foo() since it's a routine that exists, it just isn't very useful to do so
  • prints false: You can't call foo() because any call that does so will generate an error, so it's essentially not callable/useful
  • prints the compiler error: Even asking the question about whether you can call foo() will generate the compiler error even though you haven't actually called it

Your case seems similar in that it's correctly saying "I can't call that", but maybe not giving back as much information as desired. Maybe the approach would be to have the sort module do something before falling back like seeing whether there are any methods named '.key' or seeing how many candidates there are for the call and issuing an error if there are more than one. Or maybe canResolve() needs to be redesigned in some way. Anyway, I would be fine with an issue being opened for this to capture the surprise and confusion, as that's completely reasonable. I'm just not sure what the best path for resolving it would be offhand.

Hope you've been well,
-Brad