Skip to content

Enhance the Cons section to say this is as type-safe as streams can be. #1260

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 19, 2025
Merged

Enhance the Cons section to say this is as type-safe as streams can be. #1260

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions content/courses/ada-in-practice/chapters/streams_api_flexibility.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ to send and receive more complex data types. If so, how can the device driver
support them?

We certainly don't want the clients to do unchecked conversions everywhere.
That's error-prone, because it prevents the compiler from checking the usage,
That's error-prone, it prevents the compiler from checking the usage,
and makes clients responsible for what should be an internal implementation
detail.

Expand Down Expand Up @@ -608,19 +608,22 @@ Limited types do not support the stream I/O attributes by default, but
developers can define them. Note that this is not a problem for the
generic-based approach, because we declared the generic formal type as
:ada:`limited` and wouldn't need to do anything within the generic that would
contradict that.
The client's generic actual type can then be either a limited type or not.
contradict that. The client's generic actual type can then be either a limited
type or not.

When multiple types are being sent and received, the sender and receiver must
be coordinated so that the next value consumed from the stream is of the type
expected by the receiver. For example, the next value in the stream might have
been written by the sender as a floating-point value, via
:ada:`Float'Write (...)`. The receiver must use :ada:`Float'Read(...)` to
consume that value from the stream. Arguably, this is not really a *con*
because it's true for any stream when multiple types are involved. It's even
true across programming languages |mdash| see
because it's true for any stream when multiple types are involved. Even if we
used the generic-based approach, developers could instantiate the generic multiple
times with different types and send their values via the same port. With streams this
approach is as type-safe as it can be.
However, see
:ref:`Note #2 <Ada_In_Practice_Using Streams_Note_Generic_Dispatching_Constructor>`
below.
below for a possible mitigation.


Relationship With Other Idioms
Expand Down
Loading