I do not think this is necessary. You can make the Print features private, hiding them from the user.

class MyStream : public Stream{
 public:
 int available() { return 0; } //Fill in these as appropriate.
 void flush() { return; }
 int peek() { return -1; }
 int read() { return -1; }
 
 private:
 using Print::print;
 using Print::println;
 using Print::write;
 size_t write( uint8_t data ) { return (void)data, 0; }
};
MyStream stream;
void setup() {
 stream.read(); //Fine
 stream.println(); //Compile error
}
void loop() {}

flush() is part of Stream, but you can also move it to the private section.

@Chris--A: That's a workaround, but not a good one:

void print_some_things(Print& p) {
 p.println("Hello world");
}
MyStream stream; // using your definition
void setup() {
 stream.read();
 print_some_things(stream); // oops. This compiles just fine
 static_cast<Stream&>(stream).println("oops again");
 Print* p = &stream;
 p->println("Oops");
}

The existence of an ineffective workaround is not sufficient justification for an improvement being unnecessary.

That isn't really an issue either. My workaround hides the print features when using the object directly, and for the cases that the object is cast to one of its inherited types, the print functionality has no effect.

A library shouldn't be left up to assumptions, if you don't support print features, then make it well known, or don't even mention it, then no one would have a reason to use them.

Another option using my original example is to make the Stream base private and only expose what you want:

class MyStream : private Stream{
 public:
 int available() { return 0; }
 void flush() { return; }
 int peek() { return -1; }
 int read() { return -1; }
 using Stream::find;
 using Stream::findUntil;
 using Stream::parseInt;
 using Stream::readBytes;
 using Stream::readBytesUntil;
 
 private:
 size_t write( uint8_t data ) { return (void)data, 0; }
};
MyStream stream;
void setup() {
 stream.read(); //Fine
 stream.find('a'); //Fine
 Stream &s = stream; //Compile error
 Print &p = stream; //Compile error
}
void loop() {}

Similar to the above, you can also have a Stream reference or pointer as a member variable and only expose the input functions.

You've made the valid point that I've justified this poorly, so I've added some example code in my description.

A library shouldn't be left up to assumptions, if you don't support print features, then make it well known

That's kinda the point of this patch. There is currently no way to make it known that you support read features but not print features, yet there is a way to express the inverse. Why should things be this way?

What if I want to write a function that can read from Serial and stream? That seems perfectly sane, but your latest response doesn't allow that without templates.

Look at this another way - if IStream did exist, can you think of a single reason it should be removed?

flush() is part of Stream, but you can also move it to the private section.

Good catch, this probably doesn't belong in IStream as I have it here, since it deals with output and not input

flush() is part of Stream, but you can also move it to the private section.

Also see #2387.

@matthijskooijman: Was tempted to fix that too. What's stopping that being merged?

@eric-wieser, Nothing that I can see, apart from maybe lack of developer time.

Now that #2387 is merged, I've rebased this to be even simpler

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}