this might be bad, what do you think @zdevito ?

I would not make this struct part of the Operator class. I want to move away from exposing users directly to the Operator class (and instead have them directly call .op with the op implementation and options). So I think Options should be its own class. Putting it in its own header will help separate out the depenendencies (i.e. the options rely on alias_analysis, but the operator header does not rely directly on it).

Making AliasAnalysisFunction a pointer rather than an enum doesn't buy us anything here, but it does strongly couple it to the alias_analysis.h header. How about just an enum in a separate header:

enum AliasAnalysisKind {
   CREATOR,
   EXTRACTOR, 
}

struct Options {
};

We can add more wildly customizable versions by patching options when necessary.

I agree. The analyzeFoo functions in alias analysis are not really designed for outside consumption and are probably not clear to users. I think we could have an enum that covers the most common cases:

• Purely functional (no aliases, no mutation on inputs).
• View (output aliases input)
• Free for all (all inputs may be written to, all outputs may alias any input)
• Look at the schema (reads a user-provided schema, allows people to do whatever fancy thing).

reads a user-provided schema

@suo Not sure I follow how this would work

To be clear, you don't have to put all of those options in this PR (just wanted to enumerate some common cases we'll want to add later).

For "Look at the schema"—people defining a custom op can pass a JIT schema if they want; so they should be able to instruct the alias analysis pass to use that schema to populate alias info (similar to how we do with builtin ops).

These should be exposed in RegisterOperators::op() as well since that's the suggested way to register ops in the docs/tutorials