When your name is already the platform's

Summary#

Every app has the Osyrin core namespace in scope with no using to write, and that namespace exports 82 type names, many of them ordinary English words: Slot, Group, Match, Point, Month, Schedule, Now, Uri, Connection, Failure, Position, Display, Cursor, Pending, Visitor …

Declaring your own type with one of those names is legal, and yours wins. A bare Slot anywhere in your app means your Slot, in every position — a property type, a local, a parameter, a cast, an enum member access. The compiler says so once, as a note at the declaration (INFO, not a warning — nothing is broken and nothing is owed), and the platform's type stays reachable by its full name (Osyrin.Workflow.Slot). Nothing needs renaming: if Slot is the word your domain uses, keep it.

The one exception is the eleven built-in type names (DateTime, Json, Zone …) — see [[#built-ins]]. Those resolve ahead of everything an app declares and have no full spelling, so a type of yours named after one is unreachable. The compiler warns about those too, and there the remedy is to rename.

Signature#

enum Slot { Morning, Afternoon }        // legal — and a bare `Slot` now means THIS one, everywhere
Osyrin.Workflow.Slot                    // the platform's, still reachable, by its full name

Description#

What happens if I name my type after a platform one?#

Yours wins — the same rule C# uses. The name you declare in your own app is nearer than a name that arrived from an import, so it is the one a bare spelling binds to. That holds in every position; there is no corner where the platform's type quietly comes back.

What the compiler owes you is to say it, and it does — once, on the declaration:

model.osy:1  INFO  TYPE_SHADOWS_ALWAYS_IN_SCOPE  `enum Slot` has the same name as 'Osyrin.Workflow.Slot',
             which is in scope in every app with no `using` to write. YOURS WINS: a bare `Slot` anywhere in this
             app means this enum, and 'Osyrin.Workflow.Slot' can only be reached by its full name from here on.

That is the whole cost of the collision: a diagnostic that mentions Slot may be talking about either type, so you need to know which one you are reading. There is nothing to accept and nothing to write down — just write the app you meant to write:

enum Slot { Morning, Afternoon, Evening }

entity Booking {
  [Required, MaxLength(120)] string Guest;
  Slot Period;                     // the property type binds to the enum above…
}

Slot PeriodOf(Booking b) {
  Slot pick = Slot.Morning;        // …and so does the local, and the member access
  return b.Period == pick ? pick : b.Period;
}

Which names are already taken?#

All 82, by the namespace each comes from. Taking one costs you a one-line note and nothing else — this is a list to recognise a diagnostic by, not a list to avoid.

A capability you use brings more names in (the UI kit's controls, for instance). Those follow the same rule and raise the same note.

How do I still reach the platform's type?#

By its full name, which is what the note prints. There is nothing else to configure:

Guid DefinitionOf(Osyrin.Workflow.Slot s) {
  return s.Definition;                      // the PLATFORM's Slot — spelled in full
}

Slot MyDefault() { return Slot.Morning; }   // …and a bare `Slot` is still yours

If you ever see a diagnostic like cannot assign 'Slot' to 'Slot' (type 'Osyrin.Workflow.Slot'), it now carries a note saying that the two words are two different types and which one the bare spelling means. That is this rule speaking at a use site.

The eleven names you cannot have#

The built-in types are not in a namespace — they are resolved first, ahead of everything an app declares, and there is no qualified spelling that could reach past them. So a type of yours named after one is unusable: the declaration itself looks fine, and the failure lands later, at a use site.

DateTime · DateOnly · TimeOnly · TimeSpan · Guid · Json · RichText · Markdown · Vector · Zone · Culture

model.osy:1  WARNING  TYPE_SHADOWS_ALWAYS_IN_SCOPE  `enum Zone` has the same name as the BUILT-IN type `Zone` …
             THE BUILT-IN WINS: built-in types resolve ahead of everything an app declares, so a bare `Zone` never
             means this enum — and there is no qualified name that reaches it either, so this enum is unusable.

Rename yours. [SuppressWarning] silences the warning but not the problem — the type stays unreachable. The full set of built-in types is Every type, in one list; the ones an entity may store are in entity members.

If you would rather have no collision at all#

You do not have to do anything: the namespace collision is a note, so no gate counts it and nothing fails. If you would rather the two names never met, there are two ways out — rename your type, or put it in a namespace of its own, which gives it a full name and stops it shadowing anything.

[SuppressWarning("TYPE_SHADOWS_ALWAYS_IN_SCOPE")] still works on the declaration if you simply want the line gone (see [SuppressWarning]), but it is no longer what the compiler suggests: a note asks for nothing, so there is nothing to put down. It IS the right tool for the built-in half above, where the warning is real.

See also#

• Every type, in one list — every built-in type in one list
• namespace — namespace X;, and why a namespaced type shadows nothing
• entity members — which of these types an entity member may hold
• [SuppressWarning] — [SuppressWarning("CODE")], and where it may sit