[Bug]: Quirks while deriving models

[dvv]

Describe the bug

I can not find the right strategy to work with visibility filters.
Below are some examples.

Please explain how to cope with.

TIA

Reproduction

Example 1:

using Reflection;

model Foo {
  id: string,
  parent_id: Foo.id,
  parent: Foo,
}

// NB: FilterVisibility _does require_ the name argument
alias GuessReadType<Type extends Model> = FilterVisibility<Type, #{ all: #[Lifecycle.Read] }, "{name}Read">;

// Duplicate type name: 'FooRead'
model FooRead is GuessReadType<Foo> {}

Example 2:

using Reflection;

// Duplicate type name: 'Foo'
model Foo {
  id: string,
  parent_id: Foo.id,
  parent: Foo,
}

// NB: FilterVisibility _does require_ the name argument
alias GuessReadType<Type extends Model> = FilterVisibility<Type, #{ all: #[Lifecycle.Read] }, "">;

model FooRead is GuessReadType<Foo> {}

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[github-actions]

🎯 Issue Triage

When using FilterVisibility (from Reflection) to derive filtered models via an alias, the compiler reports a "Duplicate type name" error — either conflicting with the derived model's own name (Example 1, using {name}Read template) or with the original model name (Example 2, using "" as the name).

Category: Bug

Area: compiler:core

🔗 [Playground Reproduction]((typespec.io/redacted)

📋 Reproduction code

using Reflection;

model Foo {
  id: string,
  parent_id: Foo.id,
  parent: Foo,
}

// Example 1: name template "{name}Read" causes "Duplicate type name: 'FooRead'"
alias GuessReadType<Type extends Model> = FilterVisibility<Type, #{ all: #[Lifecycle.Read] }, "{name}Read">;

model FooRead is GuessReadType<Foo> {}

// Example 2: empty name "" causes "Duplicate type name: 'Foo'"
// alias GuessReadType<Type extends Model> = FilterVisibility<Type, #{ all: #[Lifecycle.Read] }, "">;
// model FooRead is GuessReadType<Foo> {}

🔍 Analysis

• FilterVisibility<T, visibility, name> synthesizes a new named model type. When the synthesized name matches an already-declared model name in the same scope, the compiler reports a "Duplicate type name" error.
• Example 1: FilterVisibility uses the template "{name}Read" → synthesizes FooRead. The outer model FooRead is GuessReadType<Foo> {} also declares FooRead, causing the collision.
• Example 2: FilterVisibility with "" appears to fall back to the source model's name Foo, which again conflicts with the existing model Foo.
• The root issue is that the name the user passes to FilterVisibility ends up colliding with either the target model declaration or the source model. The compiler should either detect this conflict and provide a clear diagnostic, or the FilterVisibility semantics should be clarified so that the is <alias> pattern does not produce a duplicate name.
• Affected area: compiler type-checking / type instantiation, specifically the handling of named synthesized models from FilterVisibility.

📝 Suggested next steps

• Clarify the intended behavior: should model FooRead is FilterVisibility<Foo, ..., "{name}Read"> reuse the outer model's name (suppressing the synthesized name), or is the synthesized name always registered?
• If the synthesized name from FilterVisibility should be suppressed when used in model X is <alias>, fix the name-registration logic accordingly.
• Add a test case covering the model X is FilterVisibility<...> pattern with a name template.

Generated by Agentic Triage

[iscai-msft]

I dug into this and reproduced both examples locally against the current main (v1.15.0). Here's what's going on and how to work around it.

Root cause

FilterVisibility<T, Filter, NameTemplate> is an alias, and applyVisibilityFilter returns a Model — it does not create a brand-new named declaration by itself, it produces a model whose name is derived from NameTemplate (via the same mechanism as @friendlyName).

The problem is the is clause:

model FooRead is GuessReadType<Foo> {}

model X is <SomeModelExpression> declares a new model named X that copies the properties of <SomeModelExpression>. It does not just alias the underlying model — X becomes its own distinct type declaration. So you end up with two different model declarations that both resolve to the name FooRead:

1. The synthesized model produced by FilterVisibility<..., "{name}Read"> (named FooRead because of the template), and
2. The outer model FooRead is ... declaration itself (named FooRead because you wrote that name).

That's the duplicate. In Example 2 ("" as the template) the synthesized model falls back to reusing the source name Foo, which then collides with the original model Foo declaration — same underlying issue, just colliding with a different existing name.

I confirmed this fires as a @typespec/openapi/duplicate-type-name diagnostic once there's an operation that references the type (needed to trigger emission/dedup):

error @typespec/openapi/duplicate-type-name: Duplicate type name: 'FooRead'.

I also verified model FooRead extends GuessReadType<Foo> {} fails the same way — so this isn't specific to is, it's specific to introducing a second named model declaration on top of a template that already names the result.

Workaround: use alias, not model ... is

If you just want the filtered type under a given name, use alias instead of declaring a new model:

using Reflection;

model Foo {
  id: string,
  parent_id: Foo.id,
  parent: Foo,
}

alias GuessReadType<Type extends Model> = FilterVisibility<Type, #{ all: #[Lifecycle.Read] }, "{name}Read">;

// alias, not "model FooRead is ..."
alias FooRead = GuessReadType<Foo>;

This compiles cleanly and FooRead resolves to the single model synthesized by FilterVisibility (named FooRead via the template). No duplicate.

alias just binds a name to an existing type/expression rather than declaring a new type, so there's no second declaration competing for the same name.

Simpler: use the built-in lifecycle templates

For the common "give me the Read/Create/Update-visible shape" case, you likely don't need to roll your own FilterVisibility wrapper at all — the compiler ships Create<T>, Read<T>, Update<T>, CreateOrUpdate<T>, Delete<T>, Query<T> for exactly this:

using Reflection;

model Foo {
  id: string,
  parent_id: Foo.id,
  parent: Foo,
}

alias FooRead = Read<Foo>;

This also compiles and produces a FooRead schema with only Lifecycle.Read-visible properties (it defaults to NameTemplate = "Read{name}", but you can pass your own template, e.g. Read<Foo, "{name}Read">).

Suggestion for the compiler/docs

The confusing part is that model X is FilterVisibility<...> looks like a natural way to give the transformed model a stable name, but it silently creates a second named declaration that clashes with whatever NameTemplate produced. It'd be worth either:

• Emitting a clearer diagnostic when model X is <T> collides with a synthesized name from the RHS instead of a generic "Duplicate type name", or
• Calling this out explicitly in the FilterVisibility/@withVisibilityFilter docs ("use alias, not model ... is, when providing a NameTemplate").

[dvv]

Thank you for an analysis!

Two things stops me:

1. I can not go "use alias, not model ... is" way because the real world definitions look more complex:

model FooRead is GuessReadType<Foo> {
  some: unknown,
  other: unknown,
  ...
}

Plus I'm requested that the models do appear in openapi as named schemas.

2. I can not use Read<Foo> because it defaults to create ReadFoo whenever the model Foo appears in "read" mode.
   Say

model Foo {
  id: string,
  parent_id: Foo.id,
  parent: Foo,
}

alias FooRead = Read<Foo>;

model Bar {
  foo: FooRead,
}

would result in ReadFoo explicit schema and no FooRead exposed at all.

[dvv]

Another example of how one can not control naming:

model Foo {
  id: string,
  parent_id: Foo.id,
  parent: Foo,
}

alias FooRead = Read<Foo, "FooRead">;

model Bar {
  foo: FooRead,
}

model Baz {
  bar: Read<Bar>,
}

which result in even ReadFooRead schema.