Hi Frederick, this mailing list is a help for preparing papers proposing C++ standard changes.   As such it fulfills several tasks:  - Free discussion of ideas  - Finding potential solutions, how to change the language to get a specific new feature  - Revealing common and corner cases, for which a language change is not defined yet or would run into problems  - Reminding of old proposals with a similar direction  - Give feedback on the effect of a new feature on how the language is routinely used productively today  - Challenge the weak spots of an idea or an proposal to improve it and/or save the time of a proposal being written, if the language change has no or slim chances  - Simulate committee questions early to prepare the one suggesting and his or her paper  - Save time for the committees by improving the quality of proposals, analyze tricky effects early and filter out the proposals  - Help with the process of suggesting and formulation of proposals   All in all it will be less a free brainstorming (item 1) and more a very direct constructive or cautionary feedback to decide, which ideas have a chance (most do not) and to toughen up and preparing the idea and the one making a proposal.   Even if some participants on this list disagree with a solution, one can write a proposal paper anyway, but better take the feedback serious and either improve or give up the proposal idea. Or at least put the arguments and your counterarguments into the proposal.   If you ask, why there is no more welcoming atmosphere for new ideas and more back-padding, then also ask yourself, whether the contributors on the list giving good, but very critical advice, day in and day out are also recognized and thanked enough for their valuable work often putting many hours into writing reasons or example programs showing a point under discussion or researching old discussions and decisions.   The 'juicy stuff' has a much higher hurdle to get into the language. If you want to suggest it, prepare to have done a lot of preparatory work or openly announce, you start to work on it and only ask for very general advice (e.g. the most critical points, where you can put your focus in your further research).   For the reentrancy idea, you could propose two different ways for the standard committees and increase your chances:   Propose a standard library solution showing and standardizing the functionality you want to solve.   And in the same paper introduce a chapter for possible syntax sugar and the core language changes.   That will help with the focus on answering the correct questions.   Best, Sebastian       -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 13.02.2023 02:19 Betreff:Re: [std-proposals] int Func(void) noreentry(-1) An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Mon, Feb 13, 2023 at 1:08 AM Frederick Virchanza Gotham wrote: > > We already do this. We already have language features in C++ that hide > extra data inside each object. I really feel that I need to make a point here -- and not a point pertaining solely to the proposal in question. A few people here on the mailing list are very caught up in evaluating the uniqueness of any new idea, and once the uniqueness has been pointed out, other people then start trying to find precedents in order to justify the new idea. This really is a rotten way of thinking. A new idea can be totally new and unique, without any precedents, and still be a good idea. I have been able to give the example on this occasion of adding a virtual destructor to a class, the effect being that it causes the size of each individual object to increase. In some people's minds, this is seen as precedent that goes toward justifying my new idea. But why should I need a precedent? Even if no other language feature caused an opaque increase in the size of each object, why can't I suggest a new features that does? Like with my suggestion last year of 'continuity methods', people were really adverse to it quite simply doing something that hadn't been done before. Resistance to change can at times be resistance to progress. Sometimes I really think that this mailing list is really missing out on fluidic constructive creative conversation. People are being careful and conservative, and we're missing out on the juicy stuff because of it. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals