I marked pattern as deprecated and added some tests.

I don't know how close we are to the next Typst release, and therefore how urgent this PR is, but I can decouple it from typst/codex#19 if necessary.

Decoupling it would be nice in principle. I haven't yet commented here because the amount of changes seem quite large, but I haven't yet considered things enough to comment on whether that's unavoidable or whether it could be simplified.

If that helps, in the first commit, the main changes are in scope.rs and diag.rs.

Two thoughts:

• Instead of having _deprecated variants for the define_* methods, how about having one mutable method? So that you'd write:

  scope.define_elem::<MyElem>();
  scope.deprecate("my", "it's old");

• The MaybeDeprecated type is kind of viral here. Would it make sense to instead pass a mutable warning sink to the field access? It could also potentially be a dyn trait that is implemented by () and Sink, maybe even Engine and Vm, so that we can ignore it by passing &mut () if we don't have a Sink. I'm not sure it's really better than what you did, but worth exploring.

Instead of having _deprecated variants for the define_* methods, how about having one mutable method?

I agree the accumulation of define_* method variants is unfortunate. I can try this, but it would probably be more annoying at the call site when we already have a MaybeDeprecated (e.g., at import.rs:71), because we would need to deconstruct it.

The MaybeDeprecated type is kind of viral here. Would it make sense to instead pass a mutable warning sink to the field access?

I am not convinced this would be better. The advantage of MaybeDeprecated is that it lets us chose if and when to emit the deprecation warning (by calling access or into_inner). It becomes viral in situations where we don't yet know if a warning should be emitted (e.g., when accessing a field on a value¹). In other words, every function that currently returns a MaybeDeprecated would have to accept an additional sink argument; this sink argument would itself become similarly viral. This is a matter of personal preference, but returning a MaybeDeprecated feels cleaner to me.

Should I deprecate calc.inf as well? This was briefly mentioned in #4724 (comment).

Properly deprecating the methods that were deprecated in #5671 would likely require a new attribute for items in a #[scope] impl block. I will wait until the deprecation infrastructure is finalized to implement it (there are still some unanswered design questions above).

I opened #5798 as an alternative, with the rationale for differing design decisions in the PR description.

Closing in favor of #5798, which is more lightweight and has some other advantages.