Add typed UUID retrieval to InteractsWithData

[emrebalasar]

Proposal

Laravel's InteractsWithData trait already provides typed retrieval methods for common data types:

$request->string('name');
$request->integer('age');
$request->boolean('active');
$request->float('price');
$request->date('published_at');
$request->enum('status', Status::class);

Would it make sense for InteractsWithData to also provide typed UUID retrieval?

$uuid = $request->uuid('user_id');

With a return type such as:

\Ramsey\Uuid\UuidInterface|null

Because the typed retrieval API lives on InteractsWithData, this would not be limited to Request; it would also be available consistently across validated input and other framework classes using the trait.

Rationale

Laravel already provides strong UUID support across several layers of the framework:

• Eloquent: HasUuids
• Schema Builder: $table->uuid()
• Support Layer: Str::uuid() and Str::isUuid()

However, at the data-entry boundary (Request / InteractsWithData), developers are still left working with raw strings.

For modern PHP codebases that favor strong typing and value objects, being able to convert incoming UUID data into a typed UuidInterface at the boundary feels like a natural missing piece in that existing UUID support.

Semantics & Design Considerations

One design question is how invalid values should behave.

The existing typed retrieval methods do not all use identical semantics:

• integer() performs a tolerant cast.
• enum() relies on tryFrom() and may return a default value or null.
• date() may throw when parsing an invalid value.

One possible UUID behavior could be:

missing / empty → null
valid           → UuidInterface
invalid         → parsing exception

similar to date(), although a more tolerant or fallback-oriented approach could also be considered.

Next Steps

The main question is whether converting UUID input into a UUID value object fits the intended direction of Laravel's typed data retrieval API.

If the core team is open to this addition, I would be happy to submit a focused PR with implementation and tests.

[HIRATRA]

This makes sense conceptually, but I think the main design question may be the return type rather than the uuid() method itself.

InteractsWithData is part of the framework's general data-access layer, so returning Ramsey\Uuid\UuidInterface would make Ramsey's UUID abstraction part of that public API.

Would it be worth considering returning Laravel's existing UUID value type instead, or otherwise keeping the parsing implementation behind a Laravel abstraction?

Another option could be to make the behavior consistent with the existing date() helper: return a typed value when present, return null for missing input, and let invalid input throw a well-defined parsing exception.

I think the API would be useful; I'd mainly want to make sure the choice of UUID value object doesn't unnecessarily couple InteractsWithData to a specific implementation.