On Sun, Oct 1, 2017 at 4:17 AM, Stefan Fuhrmann <[email protected]> wrote:
> > > On 24.09.2017 23:03, Branko Čibej wrote: > >> On 24.09.2017 22:05, Daniel Shahaf wrote: >> >>> Branko Čibej wrote on Sun, 24 Sep 2017 21:56 +0200: >>> >> >... > *for*-scope variable declarations, that'd make some sense. But talking >>>> about just "C90 + //" is, IMO, a waste of time. >>>> >>> Right. "Change the accepted set of compiles so we can use // comments" ... Wat? > About //-comments specifically, my thinking was that if we supported such >>> comments we wouldn't run into "//-comments v. /**/-comments" conflicts >>> when updating our embedded utf8proc. >>> >> Seems like the real question is related to utf8proc, rather than comment style. >... > The problem with the feature cherry-picking approach is that we don't >> have a reliable way for compilers to warn about when /other/ features >> except the blessed ones appear in the code. >> >> If we want to take the Great Leap Forward, I'd prefer to just move to >> C99 lock, stock and barrel instead. That would likely cause problems to >> some of our downstream users, however. >> > > I fully agree with Brane on this. > Concur. > Another thing that has popped up in the past and that I, personally, > would love to see happening is supporting C++ inside our libs. I think > that would have it made easier to me, using wrapper classes / templates > with appropriate operator overloading, to migrate code from one API / > data structure to another. > Yeah. It would be great to start using some C++ within include/private/, and the implementing modules. It is difficult to see how we could place any C++ into our public API, however. And yeah, I know you didn't mention that. :-) > However, that move too, would create all sorts of compatibility issues > with rules to address them and all for a limited increase in coding > convenience. > Right. Like /*..*/ comments versus // Cheers, -g
