DEV Community: Akira Shimodate

Are User-Defined Literals Necessary in C#?

Akira Shimodate — Fri, 20 Mar 2026 12:22:46 +0000

A Step Toward Meaningful Values

Conclusion

This is not a new idea.

👉 It is a continuation of how C# has been evolving.

Giving meaning directly to values is a natural evolution of C#.

C# has been moving in this direction for years.

This article proposes User-Defined Literals (UDL) as a natural
continuation of that evolution.

The Current Limitation

var duration = 123;

We don't know:

seconds?\
milliseconds?

No meaning.

Current Solution

123.Milliseconds()

Meaning depends on API.

The Core Problem

Traditionally, meaning is attached after the value is created.

UDL shifts that boundary.

Values themselves have no meaning.

Proposal

var duration = 123_ms;

Now:

Type is known\
Meaning is known

Meaning is embedded in the value.

Why This Is Natural

C# has already evolved:

foreach (pattern-based)\
await (pattern-based)\
using (pattern-based)

Language privileges have been opened.

Common Misconception

Literal = compile-time constant

Not true.

var s = $"{DateTime.Now}";

Literal is syntax, not evaluation timing.

Summary

APIs attach meaning later\
Literals carry meaning immediately

This is not syntax sugar. It's a design shift.

Final Thought

So the real question is:

Should values themselves carry meaning?

And if so:

How far should C# go in that direction?

I'm curious how others see this.

Is this a natural evolution of C#,
or are we just moving complexity from APIs into the language itself?

Why C# Keeps Opening Its Syntax (And Why It Matters)

Akira Shimodate — Fri, 20 Mar 2026 11:57:17 +0000

Conclusion

C# has been evolving in a very specific direction:

👉 It is gradually giving language-level privileges to user-defined types.

This is not accidental.
This article explains why.

C# has been evolving in a very specific direction:

Language-level privileges are gradually being opened to user-defined
types.

This article explains that evolution and why it naturally leads to the
idea of giving meaning to values themselves.

Early C#: Permission by Type

In early C#, language constructs were tightly bound to specific types.

foreach (var item in collection)
{
}

This required IEnumerable.

This construct only works if your type implements this interface.

Modern C#: Pattern-Based

Today, it's different.

public class MyCollection
{
    public Enumerator GetEnumerator() => new Enumerator();

    public struct Enumerator
    {
        public int Current => 0;
        public bool MoveNext() => false;
    }
}

The compiler now cares about behavior, not type.

This Pattern Repeats

using → Dispose()
await → GetAwaiter()
deconstruction → Deconstruct()
collection initializer → Add()

Language features are no longer exclusive.

Why This Change Happened

Meaning should not be trapped inside APIs.

TimeSpan.FromMilliseconds(123)

123.Milliseconds()

The latter embeds meaning directly into the value.

Syntax as a Shortcut for Meaning

APIs are read sequentially\
Syntax is recognized instantly

Syntax reduces cognitive load.

The Next Question

Can values themselves carry meaning?

var x = 100;

This has no meaning.

Direction of Evolution

Meaning in types\
Meaning in behavior\
Meaning in syntax

Meaning in values

Related Proposal

I proposed a concrete idea based on this direction:\
(https://dev.to/shimodateakira/why-cant-user-types-have-literals-in-c-3ln1)

C# is no longer just a language for writing programs.

👉 It is becoming a language for expressing meaning directly.

Summary

C# is evolving from type-centric to meaning-centric.

And naturally:

Toward embedding meaning directly into values.

Why Can't User Types Have Literals in C#?

Akira Shimodate — Sun, 15 Mar 2026 03:52:08 +0000

Why Can't User Types Have Literals in C#?

This is about a simple question:

Why can built-in types have literals, but user-defined types cannot?

C# allows us to write literals like this:

123L
1.5m

These suffixes change the type of the literal.

L → long
m → decimal

This syntax is extremely convenient and natural.

But it raises an interesting question:

Why is this feature limited to built-in types?

What if user-defined types could have literal suffixes too?

For example:

var t = 100_ms;
var p = (1920,1080)_pt;
var r = "abc.*"_regex;

These could mean:

100_ms → TimeSpan
(1920,1080)_pt → Point
"abc.*"_regex → Regex

In other words, user types could participate in literal syntax.

The Current Way

Today, we typically write something like this:

var t = TimeSpan.FromMilliseconds(100);

If user-defined literals existed, we could instead write:

var t = 100_ms;

The meaning would be identical.

But the code becomes closer to the domain.

Another Example

Point

Current code:

var p = new Point(1920,1080);

Literal version:

var p = (1920,1080)_pt;

Regex

Current code:

var r = new Regex("abc.*");

Literal version:

var r = "abc.*"_regex;

These examples show how domain types could become first-class literals.

How Could This Be Defined?

One possible syntax could look like this:

public static TimeSpan operator _ms(double v)
    => TimeSpan.FromMilliseconds(v);

Then we could write:

var t = 100_ms;

Another example:

public static Point operator _pt((int x, int y) coords)
    => new(coords.x, coords.y);

var p = (1920,1080)_pt;

This gives user types an entry point into literal syntax.

Why Extension Properties Aren't the Same

A common alternative might be something like:

100.ms

But semantically this is different.

Extension property interpretation:

100
↓
int
↓
extension property
↓
TimeSpan

Literal interpretation:

100_ms
↓
TimeSpan

The difference is subtle but important.

Extension properties operate on values.

User-defined literals change how the literal itself is interpreted.

Why Doesn't C# Already Have This?

Most programming languages treat literals as built-in type privileges.

For example in C#:

123
1.5
"abc"

These are tied directly to built-in types.

Allowing user-defined literals would affect multiple parts of the compiler:

lexer
parser
type binding
IDE tooling

Because literals sit at the core of language syntax, they are traditionally restricted.

But Some Languages Already Do This

C++ introduced User Defined Literals (UDL).

auto t = 100ms;

This allows conversions like:

literal → user type

And it works surprisingly well in practice.

Potential Use Cases

User-defined literals could improve expressiveness in several domains.

Units

var delay = 100_ms;
var distance = 1.5_km;

Physics / Simulation

var velocity = 30_mps;
var gravity = 9.8_mps2;

Regex

var regex = @"^[a-z0-9_]+$"_regex;

SQL DSL

var query = $"select * from Users where id={id}"_sql;

UI Coordinates

var p = (1920,1080)_pt;

In these cases the code becomes closer to the domain language.

A Type System Perspective

This idea isn't just syntactic sugar.

Today C# effectively has:

literal authority → built-in types

User-defined literals would expand this to:

literal authority → any type

In other words, it would give user types literal citizenship.

This touches on deeper questions about type system design.

Proposal

I wrote a more detailed proposal here:

https://github.com/dotnet/csharplang/discussions/9605

I'd be curious to hear what other C# developers think about this idea.

Would user-defined literals make C# more expressive,
or would they introduce unnecessary complexity?

Discussion and Counterpoints

This idea has also sparked discussion on Reddit, where a number of interesting counterpoints were raised:

[https://www.reddit.com/r/csharp/comments/1rw6fwd/proposal_userdefined_literals_for_c/]

One recurring argument is that UDLs are effectively no different from extension methods.

While that comparison makes sense at the implementation level, I think it misses an important distinction in how meaning is expressed in code — which is the main motivation behind this proposal.

Introducing VirtualStorageLibrary: A .NET Solution for In-Memory Tree Structures

Akira Shimodate — Tue, 20 Aug 2024 01:12:56 +0000

repository: https://github.com/shimodateakira/VirtualStorageLibrary

Hello Dev.to,

I'm excited to share a project I've been working on called VirtualStorageLibrary.
It's a .NET library designed to manage in-memory tree structures, including items, directories, and symbolic links.

Here's an introduction to the library:

Project Overview and Purpose:

VirtualStorageLibrary is a .NET library that operates entirely in-memory and
provides a tree-structured collection. This library offers a foundation
for managing hierarchical data structures, supporting items, directories,
and symbolic links that encapsulate user-defined types (generic types defined by the user).

This library is not a file system.

Instead, it was redesigned from scratch to create a more
flexible and user-friendly tree structure. The library aims to make it
intuitive to reference, traverse, and manipulate nodes by specifying
paths.

Project Background:

The collections provided by .NET are linear, including types like hash sets,
arrays, lists, and dictionaries, which inherently have a linear structure (such as arrays and lists).
In contrast, common file systems can be viewed as tree-shaped collections, where
elements are managed as nodes in a hierarchical structure. While there are
existing libraries that support tree-shaped collections, I couldn’t find one
that models a file system-like structure. Therefore, I conceptualized a
logical interpretation of a file system and asked, "Can we implement a tree
collection purely as objects?" The goal was to create a system that can
flexibly manage hierarchical and allow intuitive access.

Key Features:

Flexible Tree Structure
Hierarchical structure based on parent-child
relationships, enabling flexible node management.
Various Nodes
Items, directories, and symbolic links, including
user-defined types .
Intuitive Node Operations via Paths
API for referencing, searching, adding,
deleting, renaming, copying, and moving nodes using paths.
Link Management
Symbolic links managed with a link dictionary, tracking
changes in target paths.
Circular Reference Prevention
Detects and prevents circular references in paths involving
symbolic links by throwing an exception.
Flexible Node List Retrieval
Retrieves node lists within directories, filtered, grouped, and
sorted by specified node types and attributes.

Anticipated Use Cases:

Natural Language Processing (NLP)
Knowledge Base Systems
Game Development
Hierarchical Clustering
Education and Learning

Development Status and Future Plans:

The current version is 0.8.0 (prerelease).
As of 2024/08, all essential features for version 1.0.0 have been implemented.

However, some bug fixes, around 30 feature improvements, and refactoring tasks remain.

With version 0.8.0, we aim to gather user feedback, including bug reports and feature enhancement suggestions.

Simultaneously, we plan to work through the remaining tasks for version 0.9.0, targeted for release in October 2024.

During this period, class names, method names, property names, and other elements in the library may change, merge, or be deprecated without notice.

Detailed information will be provided in the release notes, so please check them for updates.

For more detailed information on the current issues and planned improvements, please visit the following page (content in Japanese):

https://github.com/users/shimodateakira/projects/3/views/3

Thank you for your interest, and I look forward to your feedback.