The linked PR is one possible approach, but we can use this issue to discuss alternatives!

I'm a bit concerned that just one attribute makes distinction kind-of implicit. When we have two implementations for two different profiles, we see that there're two implementations. Would it be more explicit if we have to implementations - one spelled out and one intrinsic, and decorate those for use in different cases?

I can see this to be helpful beyond code generation. Maybe the attribute could be SimulatableIntrinsic and the implementation is only used by the simulator but intrinsic for all other evaluation backends.

I'm a bit concerned that just one attribute makes distinction kind-of implicit. When we have two implementations for two different profiles, we see that there're two implementations. Would it be more explicit if we have to implementations - one spelled out and one intrinsic, and decorate those for use in different cases?

The reason I lean toward keeping them in one has to do with how we compile. If I have two definitions of a callable with the same name in the same scope, it produces a duplicate definition error. The way that works with @Config today is that the attribute forces one of those to be conditionally compiled out based on compilation target. We can't do that with a simulator because simulation is not a compilation target; you can be compiling for "Unrestricted" or "Base" and they both work with simulation. There might be ways to do some automatic implied target switching based on the scenario/feature we are compiling for, but I think there is other overhead to consider like whether both need to have doc comments and the behavior of things like go to definition... overall I prefer having a single item in this case.

I can see this to be helpful beyond code generation. Maybe the attribute could be SimulatableIntrinsic and the implementation is only used by the simulator but intrinsic for all other evaluation backends.

I debated on the naming in the naming quite a bit in the linked PR... I used CodeGenIntrinsic but I think SimulatableIntrinsic could also work. The key thing I want to think of is how we would document the string and what the name would imply to someone who hasn't read the documentation. On the one hand, CodeGen describes when it's treated as intrinsic, but relies on knowing the shorthand for "code generation" and doesn't quite capture the fact that it's also intrinsic for circuits and resource estimation. Simulatable is also descriptive, but feels like an awkward term for some reason (that might just be in my head). I'm eager to hear what others think of the term.

Another option that is possible but would require some more work in updating the parser is to have it not be attribute based at all but rather extend the existing body intrinsic generator to allow for a block. So we would support both the existing:

operation MyGate(q : Qubit) : Unit {
    body intrinsic;
}

and additionally support:

operation MyGate(q : Qubit) : Unit {
    body intrinsic {
        // Put simulator-only implementation here.
    }
}

While that might be a neat syntactic trick, I don't think it's as descriptive as having an attribute which at least provides a string for the user to search for in docs.

A few more points that have come up in discussion over the last week:

• Another benefit of attribute vs new "body" syntax is that it's easier to quickly turn it off and on, as you only need to add/remove or comment/uncomment one line.
• @minestarks added a +1 to the suggestion from @msoeken to use a name that is more specific to simulation, since that's what the implementation is used for.

Given these two, I want to focus in on finding a good attribute name. Here's some we have brainstormed so far, would love to hear some more!

1. SimulatableIntrinsic
2. SimulationFallback
3. SimulationOnly
4. SimImpl

Given these two, I want to focus in on finding a good attribute name. Here's some we have brainstormed so far, would love to hear some more!

1. SimulatableIntrinsic
2. SimulationFallback
3. SimulationOnly
4. SimImpl

I don't have more suggestions. I think all of them are very descriptive, but SimulationOnly could indicate that this operation cannot be used anywhere else except for simulation.

• Another benefit of attribute vs new "body" syntax is that it's easier to quickly turn it off and on, as you only need to add/remove or comment/uncomment one line.

@swernli I don't mind the attribute, but I will quibble with this... commenting out the @NameTBD() attribute has the same effect as commenting out body intrinsic in the hypothetical new syntax. Both are a one-line change.

I like SimulatorOnly.

FWIW I also like the idea of just reusing the @Config() attribute for this, and call it @Config(Simulator) . Yes we'd have to make a special case for it but I feel like we've taken enough liberties with how we implemented @Config() that I don't think this feels like a reach.