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

[pat-rogers]

Stress that streams can contain values of multiple types by definition, so this is as type-safe as can be.

Do some minor formatting and polishing.

[pat-rogers]

On 19-Sep-25 7:01 AM, Gustavo A. Hoffmann wrote: ***@***.**** commented on this pull request. ------------------------------------------------------------------------ In content/courses/ada-in-practice/chapters/streams_api_flexibility.rst <#1260 (comment)>: > @@ -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, Minor nitpick: I'd replace the first comma by a colon, i.e.: ⬇️ Suggested change -That's error-prone, it prevents the compiler from checking the usage, +That's error-prone: it prevents the compiler from checking the usage,

No, I disagree, that would have the same meaning as including the word "because" in the first version. It is error-prone in itself, and also prevents the compiler from checking for those errors...

[pat-rogers]

-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, OK, I finally understand... Maybe the word "and" could be added after the comma?

Although some might, it wouldn't be right to do it. We're enumerating a list, saying "It's A, B, and C." Each is a stand-alone item. In other words, it's error-prone in itself, not because the compiler cannot check the usage. The "and" is implicit and awkward if explicit. The last (explicit) "and" is needed only so that it reads smoothly, telling the reader that the next thing in the list is the last one.

(That being said, I'll just move on and merge the pull request as it is now.)

OK, thanks!