Aaron Hsu writes:
The standard has, as a whole, favored the introduction of new procedure names to handle new options for procedures that do effectively the same thing. In some cases this makes a bit of sense, as it would be unwieldy to do otherwise. However, there are other places where this does not make sense, and in particular, places where parameters, which we provide, could more readily be used. These places include procedures that provide behavior which is inherently dangerous and ought not to receive a full procedure name. The write procedures come to mind. The include and include-ci forms also come to mind. Adding more names doesn’t scale well, and I think we’ve gone wrong here.
The WG decided by unanimous consent to take no action on this ticket.
Au contraire. If that were done, the only way to call write with predictable results would be by always wrapping it in a parameterize form, which is longer, less clear, and more error-prone (what happens when you set the parameter to a meaningless value?) The reference to include and include-ci is misconceived: syntax forms are not affected by the state of (run-time) parameter objects, and without low-level macros there are no such objects at compile time.