At 2025-09-01T14:07:44-0400, Thomas Dickey wrote: > On Mon, Sep 01, 2025 at 07:58:05AM -0500, G. Branden Robinson wrote: > > Thomas, would you welcome further work along these lines? > > I think that could make some existing programs fail to compile. > > I've broken existing programs only in cases where I saw no other way > to add new functionality, and kept in mind that for those cases, > users would want to compile/run the same source with different > versions. > > > +/* the API has sometimes used `int` where `bool` was more > > appropriate */ +#define NCURSES_INT_OR_BOOL @NCURSES_INT_OR_BOOL@ > > agreed. But changing the API doesn't add functionality (the ABI > changes that I have in mind do _that_).
I think there is an advantage to minimizing the number of internal inconsistencies in an API. The (n)curses interface is huge and, in my opinion, a bit intimidating to familiarize oneself with. As far as I can tell (I looked[1]), none of PDCurses, PDCursesMod, nor NetSBD Curses has yet adopted `use_extended_colors()`; narrowing the data type of its return value, even if only for nit-picky consistency, is better done before they adopt it than after. I may have made an erroneous assumption that your inauguration of ABI 7 development meant that you were contemplating numbering the next ncurses release "7.0". Under "semantic versioning"[2] and other general (if vague) expectations, that would be the perfect time to make a breaking change. Would you prefer me to hold this return type change idea in abeyance until you decide upon (and announce) crossing the 7.0 Rubicon, or should I discard it entirely? Separately, what is your opinion of making the man pages products of `AC_SUBST()` and `AC_OUTPUT()`? Regards, Branden [1] https://github.com/wmcbrine/PDCurses https://github.com/Bill-Gray/PDCursesMod https://man.netbsd.org/curses.3 [2] https://semver.org/
signature.asc
Description: PGP signature
