proposal draft - annotated C++ template parameter packs

658 views
Skip to first unread message

George Makrydakis

unread,
Jun 15, 2014, 2:32:42 PM6/15/14
to std-pr...@isocpp.org
Hello to std-proposals and its meticulous readers.

A few days ago in another thread, I announced that I would soon be producing an initial draft on an idea of how to properly extend template parameter pack semantics. A couple of weeks later I think that the ongoing draft is at a stage where it should start facing some public scrutiny, despite it is an incomplete and uncorrected work so far.

The reason I am doing this is because I want to further enchance the pattern matching capabilities template parameter lists offer through class template partial specializations and function template overloads in all levels where templates are involved (meta-programming and non).

I am not looking for a convenient shorthand for specifying a fixed size parameter pack for any of the three template parameter types within the declaration of a template parameter list. While such a vision may have some benefit combined with initializer lists and non-type parameters, I think it does not actually address the real issues. Such behavior is anyway a limit case scenario of what I am working on. I believe that the work you will find in this draft provides a more cohere alternative that should interest the EWG.

The core of this draft proposal is about extending parameter pack semantics through optional annotation by adding two "annotators" immediately after the pack identifier has been specified in a template parameter list.

The proposed "annotators" are just { } and [ ] enclosures for constant expressions abstracting sets of pack sizes and parameter patterns from which the pack is to be composed of according to programmer intent. This would reduce the need for source code boilerplate for several class template partial specializations, function template overloads and sfinae (ab)use in order for pattern matching to be a useful computational construct within a given translation unit with lower cost of use. People who have been using things like vertical and horizontal code generation through preprocessor meta-programming like in boost, are aware of the problem of boilerplate when templates are used computationally. Not everything is doable through recursive instantiations wherever many class template partial specializations and function template overloads are needed for pattern matching purposes.

There are no breaking changes involved since the use of such annotators is completely optional; they have been engineered to degenerate to either non-empty/empty parameter packs, single parameters and explicitly specified parameter sequences, thus having equivalent forms to which they degenerate; they also obey partial ordering rules and offer sfinae for invalid expressions at a template parameter list level.

There is a non-trivial series of pages that tries to pinpoint the size and pattern constraints for sets of templates that can be clustered into single template parameter lists. People who are just interested in "code" can look at the last sections where the use of annotated template parameter packs lead to trivial implementations of typelists and compile-time "block" switches. Code in the context of this draft is compared with code that is currently valid C++11 / C++14. The "block switch" example is offered as an attachment in this email for people who want to compile it in C++11 / C++14 mode.

There are some things that lack full exposure. There are other things that need more attention in order to be unambiguous in wording. There may be some seeming errors and typos. This is not a final and complete draft, but it is an initial attempt for studying this in good will with anybody who wishes to.

You will find my first PDF draft as an attachment to this email for paper trail purposes. I will regularly update it and write about it over at http://atpp.irrequietus.eu. I will discuss it on this thread with whoever is interested. Please be patient if my replies delay, I am certain you all have tight time schedules as I do.

Closing, I would like to thank Ville Voutilainen, current secretary of the C++ standard committee for strongly motivating me to approach the problem. Fixed size parameter packs are an ongoing work by Maurice Bos in another thread of this mailing list. The two approaches are fundamentally different.

Once it gets the form I am fully satisfied with, I will apply for the N number and notify this mailing list thread.

Thanks a lot for reading,

George

atpp-7d4fb49.pdf
block.cc

George Makrydakis

unread,
Jun 16, 2014, 4:09:03 PM6/16/14
to std-pr...@isocpp.org
I have now placed the proposal source in a git repository at https://github.com/irrequietus/atpp for those who want to track changes than only periodical snapshots. Thanks to Gerhard Röthlin (cbreak) for privately providing feedback and pointing out an obvious constant expression error in 7d4fb49/63. Current reference material is now bdb29d2 at http://atpp.irrequietus.eu/atpp-bdb29d2.pdf

Latest PDF build that is good to go for reference purposes is always the most recent at http://atpp.irrequietus.eu.

George Makrydakis

unread,
Jun 19, 2014, 10:40:14 AM6/19/14
to std-pr...@isocpp.org

I have had the pleasure of discussing this with the EWG in rapperswil. Unsurprisingly, while the proposed semantics can cover an extremely wide area of template parameter list manipulation using extremely terse syntax, the niche interest of a such a highly generic feature - that is mainly template meta-programming oriented  - does not justify the effort required for implementing this as a language feature.

As the current draft argues,  these semantics can be implemented using currently valid C++ constructs but the boilerplate required is non-trivial. People who have interest in template meta-programming techniques for code generating purposes - like me - may have interest on this, but that does not mean average user suitability.

I will pursue the library route as a separate project,  related to template meta-programming despite its niche interest. I use that style with interesting results in another set of libraries. The draft will evolve and into a library implementation itself, unrelated to C++ standard purposes.

George

George Makrydakis

unread,
Jun 23, 2014, 4:52:12 AM6/23/14
to std-pr...@isocpp.org
The day after the presentation, the EWG started a discussion on EWG issue 30, "Efficient/Flexible Access to Argument Packs" submitted by Dave Abrahams in 2012-10-16 and asked / (delegated?) drafts. The current wording is (emphasis mine):

"There are lots of very basic manipulations that are either really hard or impossible to do with argument packs unless you use something that causes a big recursive template instantiation, which is expensive at compile-time and can cause bad error messages. I want to be able to index argument packs with integral constant expressions, "take" or "drop" the first N elements of the pack, etc."

I find it bewilderingly ambiguous, however unfortunate and fairly unjust for the EWG itself in its haste to conclude informal guidance on a non-trivial N-less draft of a sponsor-less author, to give a recommendation for a library implementation, while opening discussion for a language feature on subjects tightly related to such draft the following day. The author had asked for presentation time in an adequate setting since the consequences are non-trivial to analyze despite trivial to use and implement. Some time was given; as for the setting, in retrospect it would seem quite awkward in its details to describe it; it is the new coming author's mistake of accepting it, trusting the authoritative wisdom and well-meaning character of the EWG.

All of this is of little importance since I was evaluating the library way given that "we do not want to complicate the language". However, handling EWG issue 30 "complicates" it - and it got a drafting request yet again. In a newer discussion of this modus operandi with the EWG in meeting, some suggested completing the draft as a resolution; I feel that we are just losing the actual context of the actual complaint: conflicting guidelines ignoring work already being done is unjustified under any circumstance on technical grounds. If at all.

For the sake of consistency, the language feature proposal will be completed, regardless of the attitude towards it; it has a technical basis upon which issues like EWG 30 are definitively solved, constituting part of prior work on it. As I said before, I am working on it at a git repository open to everybody. Perhaps a future or parallel author who is more socially engaged into pursuing this, will find it useful as a conceptual supermarket of solely technical arguments for his own work. For me, it is very rewarding by itself to volunteer my work on something that can give me concrete ideas on how to improve my own template meta-programming libraries beyond the usual approaches.

In attachment, a PDF of the slides that were used in context of the current draft (sha1sum: efacc489c3ffd9b62afc65c06e3ae5e08cd43070).

atpp_slides_rapperswil.pdf

George Makrydakis

unread,
Jul 20, 2014, 7:53:53 PM7/20/14
to std-pr...@isocpp.org
Hello folks, a few unrelated necessities delayed me from proceeding with this. The a new pdf is out at http://atpp.irrequietus.eu/atpp-c79f4b7.pdf  with sha1sum of ce55b5d3936875c983a4e457c008f536aad9826a so if anybody is wondering on the latest, from the commit message you get some info on what I did:
-
Extensive rewrite of abstract, removal of cruft, fixes #2, #5, #6.

The abstract has been rewritten extensively in order to reflect the main
syntactic properties of annotation as well as why this syntax has been
selected as the most likely candidate in the introductory section.

The initial and obviously boring examples of pattern matching through
parameter patterns have been removed since the document can offer a
much better alternative as to what vertical and horizontal expansion
signify in a very succint manner within the abstract. This however is
readily evident mostly to experts (e.g. boost.preprocessor users).

The section on introduction partially addresses also issue #7, while
within 2-3 paragraphs it is attempted to clarify that parameter pack
processing features turn typelists into first-class citizens of within
a template parameter list.

Examples have been added for getting quickly acquainted with the full
form of the annotation syntax (asides ternary annotation, which is
NOT what you think it is).

References to WG21 papers related to the need of pack processing features
at the language level have been added. The subtle reference to monads
is made through the citation of work by Sinkovic and Porkolab. Concepts
are being hinted upon as being boosted by such semantics while not
able to supplant pack processing features themselves. Ternary pack
annotation is introduced and targeted for the generative aspects of
pack processing but will be discussed later on. These last two (concepts
and ternaries) are actively processed but the other sections have to
be cleaned up or it is a big mess to tell the whole story.
-

Have fun and remember to visit the issue tracker and the git repository. All related links can be found at http://atpp.irrequietus.eu. Latest git commit in the master branch always invalidates whatever else I have released in PDF form. I expect this to require some time of course due to ternary annotation and concept interaction, but small adjustments should be common from now on. It is not finished yet, but it gives a cleaner idea on how this relates directly to issues like C++ EWG 30 - which is not actually tiny at all - and the current bibliography on things strictly refering to template meta-programming which this should affect for the better.

As always, open to suggestions corrections etc

Thanks a lot!

George


George Makrydakis

unread,
Jul 21, 2014, 5:30:22 AM7/21/14
to std-pr...@isocpp.org, bot...@mozilla.com

It just came to my attention that Botond Ballo in his http://botondballo.wordpress.com/2014/07/17/trip-report-c-standards-committee-meeting-in-rapperswil-june-2014/ reports this to which I have to reply in this mailing list:

Quote: "A rather complicated proposal for annotating template parameter packs that claimed to be a generalization of the proposal for fixed-size template parameter packs. Rejected because it would have made the language much more complicated, while the benefit would mostly have been for template metaprogramming; also, several of the use cases can be satisfied with Concepts instead."

Reply: First, annotated parameter packs are not a proposal yet. They do not even have an N-number yet. Also, as I am about to do in successive writeups, concepts do not cover these cases for the same reason fixed size packs do not cover them or can be supplanted by concepts; instead there is some nice interplay with them. Also there was not a vote casted nor it was asked for. A library reccomendation was given. Finally, it is not a generalization of fixed parameter packs; it has fixed size parameter packs as a limit case scenario. The fears of complication are also being addressed properly.

Quote (for fixed size parameter packs): "EWG liked the idea, but had some concerns about syntactic ambiguities. The proposal also inspired an offshoot idea of subscripting parameter packs (e.g. Pack[0] gives you the first parameter), to avoid having to use recursion to iterate over the parameters in many cases."

Reply: EWG did not notice the problem with ...[], including the author of that proposal until it was already in complete redesign phase. Annotated template parameter packs did not have these problems. Also, they did not address at all or spawn the idea of indexed based type access in a parameter pack. This was already the case with Dave Abrahams' EWG issue #30 which I did refer to when we were "discussing" my draft (no N-number and not asking for it yet until it is complete). Annotated template parameter packs already had unambiguous syntax for index-based access and also had a dedicated section within which it was evident that any kind of feature added to parameter packs even in "fixed" form would mean that index-based access would be an inevitability. Therefore fixed size packs spawned nothing in that respect.

Annotated template parameter packs are a combination of several ideas that are already lurking in the C++ community and the newest draft offers ample bibliographical evidence about the soundness of the technical argument. Just because people are scared of template meta-programming does not mean their motivation is founded, especially when the EWG "encourages" additional features on parameter packs that complicate the language even more.

Let's begin with the consequences of actually resolving EWG issue #30 and why even the committee does not think that it is actually doable with concepts; if things related to issue #30 are not resolvable with concepts perhaps they would like to properly figure out what annotated template parameter packs were conceived for.

I report this for the sake of correctness in your references, trip report and respect to who has done prior work on this instead of spoored hearsay. I expect you to revise but that does not mean you will. I consider this just an unfortunate misunderstanding on your behalf.

George

botond...@gmail.com

unread,
Jul 22, 2014, 2:04:39 AM7/22/14
to std-pr...@isocpp.org, bot...@mozilla.com
On Monday, July 21, 2014 5:30:22 AM UTC-4, George Makrydakis wrote:
Reply: First, annotated parameter packs are not a proposal yet. They do not even have an N-number yet.

I'm not sure why you object to the term "proposal". I used this term to describe several things that did not have N-numbered papers (such as expanding parameter packs as expressions, and throwing on stack exhaustion), as well as things that did.
 
concepts do not cover these cases for the same reason fixed size packs do not cover them or can be supplanted by concepts;

I said concepts cover "several" of the use cases, not all.
 
Also there was not a vote casted nor it was asked for.

I edited my post to mention this.
 
Finally, it is not a generalization of fixed parameter packs; it has fixed size parameter packs as a limit case scenario.

I don't see any inconsistency between saying "A is a generalization of B", and saying "B is a limit case of A". A rectangle can be thought of as a generalization of a square; it is equally valid to think of a square as a limit case for a rectangle.
 
Also, they did not address at all or spawn the idea of indexed based type access in a parameter pack. This was already the case with Dave Abrahams' EWG issue #30

I edited my post to say that fixed-size parameter packs "generated renewed interest" in indexed access to parameter packs, since it has been proposed previously. 

I report this for the sake of correctness in your references, trip report and respect to who has done prior work on this instead of spoored hearsay. I expect you to revise but that does not mean you will. I consider this just an unfortunate misunderstanding on your behalf.

I revised my post as described. Hope any misunderstandings have been cleared.

Regards,
Botond

George Makrydakis

unread,
Jul 22, 2014, 6:56:18 AM7/22/14
to std-pr...@isocpp.org, bot...@mozilla.com

On 07/22/2014 09:04 AM, botond...@gmail.com wrote:
I'm not sure why you object to the term "proposal". I used this term to describe several things that did not have N-numbered papers (such as expanding parameter packs as expressions, and throwing on stack exhaustion), as well as things that did.
Proposals get votes casted; this did not, it got a library recommendation which is unfounded given that it addresses things like EWG issue 30 in its core. There were no valid technical arguments provided against it for which I haven't provided a direct and cohere reply and will continue to do so in upcoming drafts. You are not mentioning that fact in your revised trip report; you summaringly label it as "rejected".

Rejection requires votes of people who have already read a paper and have sound technical arguments against it. None of these took place. Disliking an idea on the basis of non-technical arguments, then delegating the gist of it the next day to "insiders" is wrong and unjustifiable on technical grounds. It makes it even more offensive when people like you, in good will, disseminate erroneous information. Your will to rectify proves the argument.

For the record, my incomplete draft had no ambiguous syntax in the context of a template parameter list. I was not given due process (no votes, I even had to ask *several times* to get some time for this initially and get the sleepy lunch section). The gist of what I am trying to do seems to be in the soul of things like EWG issue 30. Had the EWG followed a formal path we would not be discussing about this now since they would have "seen" issue 30 and others. There are far too many details to this behavior, but I digress.


 
concepts do not cover these cases for the same reason fixed size packs do not cover them or can be supplanted by concepts;

I said concepts cover "several" of the use cases, not all.

Concepts do not have generative properties; they do not access "ranges" of types or individual types within a parameter list which is what issue 30 (and other material) is about. Concepts can be laboriously emulated through rudimentary pack manipulation; the boost libraries offer ample testament to this. Would you want to deprecate SFINAE completely because it can be abused to do concept work as well? I think not, at this stage of affairs.

Easing pack manipulation/processing makes template meta-programming less prone to being an unfortunate "error" as some people call it. Isn't that in the wishes of the EWG since they are examining issues like issue 30 ? It complicates the language? You really think that expanding packs as expressions (which is an infinitely useful thing) in the context of an unrelated proposal is not "complicating the language" as well?

Concepts lite are wonderful, but in the end just glorified and beautified SFINAE predicates making use of the parametric polymorphism parameter lists and packs represent; not the other way around. But I digress.


 
Also there was not a vote casted nor it was asked for.

I edited my post to mention this.
 
Finally, it is not a generalization of fixed parameter packs; it has fixed size parameter packs as a limit case scenario.

I don't see any inconsistency between saying "A is a generalization of B", and saying "B is a limit case of A". A rectangle can be thought of as a generalization of a square; it is equally valid to think of a square as a limit case for a rectangle.

"A dog has hair and humans have hair, therefore dogs are a limit case of humans."

We are both equipped to understand what this is. This is not even an argument and we are both equipped to understand what we are really talking about: EWG.

Pack proposals dealing with index and range access are likely to resort to the same mechanics as I, regardless of syntax (which in my case, is unambiguous as well as terse) and there were people admitting this. I thought that it was a win for the EWG to attract the interest of such technical dedication and analysis from unsponsored outsiders, since it has an open call for proposals. A posteriori, a waste of my time.


 
Also, they did not address at all or spawn the idea of indexed based type access in a parameter pack. This was already the case with Dave Abrahams' EWG issue #30

I edited my post to say that fixed-size parameter packs "generated renewed interest" in indexed access to parameter packs, since it has been proposed previously.

Political correctness is obvious here and adds more credit to the damage done, but does not change the essence of the subject. My draft addresses needs in issue ewg#30 and it was not given due course nor acknowledgment in the ewg issues list; instead, it is far from obvious that there is an attempt of shoehorning issue 30 into a proposal it did not even address (fixed packs) or others that will emerge, removing "encouragement" from a proposal that did (mine). What is the technical purpose and rationale of this? none. But I digress.



I report this for the sake of correctness in your references, trip report and respect to who has done prior work on this instead of spoored hearsay. I expect you to revise but that does not mean you will. I consider this just an unfortunate misunderstanding on your behalf.

I revised my post as described. Hope any misunderstandings have been cleared.

Your report is an unfortunate victim of impressions and not facts. These meetings are supposed to be open and respecting prior work. The fact that you partially revised, validates the fact that you were in error, yet placing it in "rejected" is still incorrect. Since you desired to provide a more detailed trip report, it is your precise duty to be checking the facts. So let's go with them:
  1. fact: It was said by an EWG member acting as an arbiter in the first part of the last Saturday EWG morning meeting, after my own raise of concern, that an honest resolution would be to promote a final version of the document. I also did not see this mentioned in the wiki, or your trip report. This and the fact that it initially got a "library recommendation", means that there was no rejection in either session. Your classification is therefore defenseless.
  2. fact: Authors have rights that cannot be "encouraged", "discouraged" or get "library recommendations" to see the gist of their work delegated elsewhere in the form of "renewed interest" political correctness. The haste of the EWG, resulted in undeniably creating the impression that unsponsored authors not related to the "insider circle" of sponsored individuals are not welcome on the basis of non-technical grounds.
  3. fact: the draft and presentation provide more than a valid match for EWG issue #30 which was not given a library recommendation as a resolution the following day.
  4. fact: My real mistake is respecting them more than they respected their own processes; the ISO acronym is a pretty heavy thing. It is probably due to this that in the early last session I got "encouraged" to continue work on this in public view, probably due to their political correctness than desire to be disproven. I "encourage" them to reflect on the consequences of their ad libitum informal character towards unsponsored first-timers.
In conclusion, right now I "feel" like the little child in the old danish tale of Keiserens nye Klæder ; I hope for their own sake that they respect my work in its final form and provide an N-number they cannot formally deny once I will request it. Whether they will like to discuss it, avoid it, obviously reject it on non-technical grounds or stem several other proposals out of it in the meanwhile, is not of my concern since it already constitutes part of prior work since Rapperswil 2014.

This is not a competition of egos on who is right and who is wrong, but about providing a proof of their - perhaps accidental but still disrespectful and questionable - misconduct. Everybody makes mistakes - even monkeys fall from trees as a Japanese proverb says. For this reason, I will retire in my silence but keep the work up and updating just the git repository, completing it soon enough to provide that proof. This way, everybody gets exactly what they merit.

Thank you for your comments and wish you creative endeavors.

George


Ville Voutilainen

unread,
Jul 22, 2014, 8:38:38 AM7/22/14
to std-pr...@isocpp.org
Some remarks:

On 22 July 2014 13:57, George Makrydakis <irreq...@gmail.com> wrote:
> Rejection requires votes of people who have already read a paper and have
> sound technical arguments against it. None of these took place. Disliking an

Well, it's unreasonable to expect people to have read a paper that did not
appear in the pre-meeting mailing.

> Your report is an unfortunate victim of impressions and not facts. These
> meetings are supposed to be open and respecting prior work. The fact that

The meetings are not "supposed to be open". WG21 kindly welcomes visitors,
but it has no obligation whatsoever to do so. As far as "unsponsored outsiders"
go, the WG21 doesn't have to listen to anyone not listed in the ISO
global directory
as an NB-designated expert member.

> fact: Authors have rights that cannot be "encouraged", "discouraged" or get
> "library recommendations" to see the gist of their work delegated elsewhere
> in the form of "renewed interest" political correctness. The haste of the
> EWG, resulted in undeniably creating the impression that unsponsored authors
> not related to the "insider circle" of sponsored individuals are not welcome
> on the basis of non-technical grounds.

I'm unaware of such "author rights". EWG can give guidance that completely
changes the intended direction of a proposal, and it has given such guidance
in the past.

> fact: My real mistake is respecting them more than they respected their own
> processes; the ISO acronym is a pretty heavy thing. It is probably due to

Perhaps you should follow the processes, including paper submission processes,
before accusing EWG of not following its own.

> In conclusion, right now I "feel" like the little child in the old danish
> tale of Keiserens nye Klæder ; I hope for their own sake that they respect
> my work in its final form and provide an N-number they cannot formally deny
> once I will request it. Whether they will like to discuss it, avoid it,

EWG doesn't play any role in providing N-numbers for proposals. They neither
accept or deny the numbers. EWG handles language extension proposals that come
in via the mailing, or via the issue list. You mentioned that you have
not been given
due acknowledgement in the EWG issue list; I will add a mention of this paper
into issue 30, but there's no "due acknowledgement" that has been denied to you
since you have submitted neither a proper proposal paper nor an actual issue.

It seems that you had quite different expectations about the process
and the meeting
than what the actual process is, to the point of having actual
misconceptions about
the process. All I can recommend is finishing your paper and trying
again, possibly via a champion if you choose to not attend a meeting yourself.

George Makrydakis

unread,
Jul 22, 2014, 10:46:43 AM7/22/14
to std-pr...@isocpp.org, ville.vo...@gmail.com

On 07/22/2014 03:38 PM, Ville Voutilainen wrote:
Some remarks:


Well, it's unreasonable to expect people to have read a paper that did not
appear in the pre-meeting mailing.

It is equally unreasonable then for people who have not read it to pass judgment at lunchtime and the following day delegate issues strongly related to it (like EWG #30) to sponsored insiders. The "fixed size parameter packs" paper for example, was also not in the pre-meeting mailing list at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-05 and appears only at the post-rapperswil 2014 mailing list at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-07. Therefore using such an argument in your defense taints your claim due to unequal treatment.

The meetings are not "supposed to be open". WG21 kindly welcomes visitors,
but it has no obligation whatsoever to do so. As far as "unsponsored outsiders"
go, the WG21 doesn't have to listen to anyone not listed in the ISO
global directory
as an NB-designated expert member.
If the meetings are not supposed to be open why do you have an open call for proposals in the website and you yourself motivate people into writing proposals? Why does the website does not say that one has to be NB member in order to be heard? What is the purpose of the std-proposals mailing list? How are people supposed to be discussing them? Why do you motivate drafting without underlining these facts? As far as "unsponsored outsiders", meaning people not working for particular employees and companies, it would be interesting to also study who "votes" for what, when, and for whom. For all of the above, your claims are invalidated due to protocol violation, e.g. by admitting non pre-mailing list N-less papers.


I'm unaware of such "author rights". EWG can give guidance that completely
changes the intended direction of a proposal, and it has given such guidance
in the past.

Prior art constitutes precedent you cannot ignore especially if you start adopting even parts of said work without due reference. The meeting happened. The EWG can do whatever it wants as long as it is coherent and submit to the consequences of a logical fallacy it has fallen into as is the case with issue #30 delegation. It is a blunder that cannot be explained on technical grounds and this is why you are partially rectifying the situation. It is not a problem of what the EWG wants though, but what are the consequences of its actions to itself. If they are not technically sound and one wishes to call that out, it is a vulnerability the EWG creates for itself. Therefore your claim of EWG being a totally objective and formal authority under such circumstances is an claim inapplicable to our discussion. That leaves it vulnerable to misconduct, whether to internal or external authors.


Perhaps you should follow the processes, including paper submission processes,
before accusing EWG of not following its own.

You allowed the processes to be bypassed by allowing proposals without N numbers to be discussed that were not in the pre-meeting mailing list. You motivated of at least two N-less proposals which was a protocol violation according to what you are saying. Also, Herb Sutter did voice his concern publicly. I will again bring in discussion my previous reply: The "fixed size parameter packs" paper for example, was also not in the pre-meeting mailing list at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-05 and appears only at the post-rapperswil 2014 mailing list at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-07. Therefore using such an argument in your defense taints your claim twice.



      
EWG doesn't play any role in providing N-numbers for proposals. They neither
accept or deny the numbers. EWG handles language extension proposals that come
in via the mailing, or via the issue list. You mentioned that you have
not been given
due acknowledgement in the EWG issue list; I will add a mention of this paper
into issue 30, but there's no "due acknowledgement" that has been denied to you
since you have submitted neither a proper proposal paper nor an actual issue.
Again, there was no N-number and pre-meeting mailing list proposal for fixed size parameter packs either but it has been passed as a proposal despite its grave syntactical ambiguities. See quotes above. This is a case of two different measures applied to two different people under the same circumstances. This is a mistake you cannot but accept and is the reason why you are modifying issue #30 and will proceed as nothing happened. This further validates my claim and invalidates your defence.



It seems that you had quite different expectations about the process
and the meeting
than what the actual process is, to the point of having actual
misconceptions about
the process. All I can recommend is finishing your paper and trying
again, possibly via a champion if you choose to not attend a meeting yourself.

This is diverting the argument of EWG  - accidental or whatever - misconduct regardless  of who is actually responsible for it, towards ad hominem which I understand due to your position as secretary. My expectation was none other than to express my specific interest for a certain feature, got a library recommendation which I said that I would eventually follow, by sending an email in this std-proposals mailing list.

Then, the EWG gave a language feature reccomendation the next day for practically same thing and that is a factual blunder so unfortunate you cannot defend; that is why you are to partially amend your writing of the facts. This kind of makes the motivation of the initial "library recommendation" questionable and is your actual unsolvable problem.

You were also present as secretary during the early part of the Saturday EWG meeting that had an arbiter in the end accepting my argument. I did not see that mentioned in the wiki but as I said in my previous email; it is not the "proposal" that counts, it is the inconvenient proof of how you (not personally, but abstractly as EWG) do things. You do not mention this in your email. This further invalidates your defense and makes me wonder less about why a lot of people submit issues but ignore motivation on writing papers.

All I can recommend is that in the future, as an active secretary of the C++ standards committee, you should never accept discussion or motivate papers that do not have N-numbers regardless of origin that have not been in the pre-meeting mailing list unless you can guarantee equal treatment for all of them.

Once my "complicated" paper is completed, I will submit it in a pre-mailing list setting, ask for an N-number referencing my talk and initial research into this subject pre-rapperswil and be done with it. I do know that the EWG will be eager to reject it but not its essence; several other proposals by "encouraged" authors will demonstrate this in time. I do not believe that anybody eager to please the kings would ever want to champion this other than me at this point :).

There is no objective reason why multiple authors cannot work together but against each other if they are all proven to be worthy of dealing with the same subject; seems like this is modeled after Prisoner's Dilemma. I would have been more than available to be "guided" from somebody of your prestigious colleagues as to how things are done providing valid technical arguments. No valid and proven technical arguments were offered, in view of other proposals that "complicate the language even further". Therefore the problem is "social"; not technical. This is just one of those huge EWG "blunders" which will be remembered as a candid anecdote on my behalf.

I do not believe we have anything more to discuss on this matter because it is far from obvious that in essence, your arguments are defenseless as any ad-hominem approaches will be. I am satisfied by my contribution in these discussions and permanent record of them so far; but I will gradually complete that paper its git repository and this is why I will not participate in anything unrelated around here.

Keiserens nye Klæder applies; the little kid exists; the discussion is concluded.

Thank you for your contribution and wish you well. See you next time, I guess.

George


PS: I still think you are one of the people with the deeper understanding of what I am talking about and I understand your difficult position; my comments are towards that position as secretary and active EWG member and do not address you personally.


Ville Voutilainen

unread,
Jul 22, 2014, 11:14:24 AM7/22/14
to std-pr...@isocpp.org
Lovely, I managed to not reply-all

On 22 July 2014 18:09, Ville Voutilainen <ville.vo...@gmail.com> wrote:
> On 22 July 2014 17:47, George Makrydakis <irreq...@gmail.com> wrote:
>>
>> On 07/22/2014 03:38 PM, Ville Voutilainen wrote:
>>
>> Some remarks:
>>
>>
>> Well, it's unreasonable to expect people to have read a paper that did not
>> appear in the pre-meeting mailing.
>>
> It is equally unreasonable then for people who have not read it to pass
> judgment at lunchtime and the following day delegate issues strongly related

If that's a concern for you, make sure people have time to read your
paper. If you
solicit feedback at the risk of people not having read your paper,
you'll get what
you'll get.


> to it (like EWG #30) to sponsored insiders. The "fixed size parameter packs"

"Sponsored insiders" as in volunteers willing to work further on the idea?

> paper for example, was also not in the pre-meeting mailing list at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-05 and
> appears only at the post-rapperswil 2014 mailing list at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/#mailing2014-07.
> Therefore using such an argument in your defense taints your claim due to
> unequal treatment.

Perhaps that paper was easier to digest, and people had time to read it.

>>
>> The meetings are not "supposed to be open". WG21 kindly welcomes visitors,
>> but it has no obligation whatsoever to do so. As far as "unsponsored
>> outsiders"
>> go, the WG21 doesn't have to listen to anyone not listed in the ISO
>> global directory
>> as an NB-designated expert member.
>>
> If the meetings are not supposed to be open why do you have an open call for
> proposals in the website and you yourself motivate people into writing
> proposals? Why does the website does not say that one has to be NB member in

In order to get useful proposals to the committee. That is, useful
proposals, as in
actual proposals, instead of papers that arrive without any
pre-warning and subsequent
complaints of such papers not getting the expected treatment.

> order to be heard? What is the purpose of the std-proposals mailing list?
> How are people supposed to be discussing them? Why do you motivate drafting

This forum provides a way to solicit feedback on proposals from random
individuals
before taking such proposals to the committee. This forum is not part
of the official
N-paper submission process in any way.

> without underlining these facts? As far as "unsponsored outsiders", meaning
> people not working for particular employees and companies, it would be
> interesting to also study who "votes" for what, when, and for whom. For all
> of the above, your claims are invalidated due to protocol violation, e.g. by
> admitting non pre-mailing list N-less papers.

I'd say your claims are invalidated due to process violation, as well. You keep
complaining about the lack of due process, without following any such process.
You keep raising the matter that another similar non-N-numbered paper
was considered
and got different treatment. Perhaps that's because EWG considered that paper to
be better?

>> I'm unaware of such "author rights". EWG can give guidance that completely
>> changes the intended direction of a proposal, and it has given such guidance
>> in the past.
> Prior art constitutes precedent you cannot ignore especially if you start
> adopting even parts of said work without due reference. The meeting
> happened. The EWG can do whatever it wants as long as it is coherent and

Oh, that's not quite right. EWG can do what it deems best. There's no
"as long as". And the technical experts in EWG, and in WG21 can decide
what they deem best based on any reasons they personally decide. I can
vote for or against a proposal and I don't even have to explain why, to anyone.

> submit to the consequences of a logical fallacy it has fallen into as is the
> case with issue #30 delegation. It is a blunder that cannot be explained on
> technical grounds and this is why you are partially rectifying the
> situation. It is not a problem of what the EWG wants though, but what are
> the consequences of its actions to itself. If they are not technically sound
> and one wishes to call that out, it is a vulnerability the EWG creates for
> itself. Therefore your claim of EWG being a totally objective and formal
> authority under such circumstances is an claim inapplicable to our
> discussion. That leaves it vulnerable to misconduct, whether to internal or
> external authors.

I haven't made a claim that EWG is a totally objective and formal authority.
You seem to be making claims that it is a biased entity that makes decisions
based on not entirely technical reasons. Well, guess what? You may be right.
The question is, so what? That's far from EWG performing actual misconduct,
whatever the definition of that is.


>> EWG doesn't play any role in providing N-numbers for proposals. They neither
>> accept or deny the numbers. EWG handles language extension proposals that
>> come
>> in via the mailing, or via the issue list. You mentioned that you have
>> not been given
>> due acknowledgement in the EWG issue list; I will add a mention of this
>> paper
>> into issue 30, but there's no "due acknowledgement" that has been denied to
>> you
>> since you have submitted neither a proper proposal paper nor an actual
>> issue.
> Again, there was no N-number and pre-meeting mailing list proposal for fixed
> size parameter packs either but it has been passed as a proposal despite its
> grave syntactical ambiguities. See quotes above. This is a case of two
> different measures applied to two different people under the same
> circumstances. This is a mistake you cannot but accept and is the reason why
> you are modifying issue #30 and will proceed as nothing happened. This
> further validates my claim and invalidates your defence.

"Passed as a proposal"? It's thus far considered as a basis for
further work, not
"passed" for any meaning of "passed". And it's not a case of two
different measures
applied to two different people - it's a case of two different
measures applied to
two different proposals. Regarding issue 30 - first you complain that there's no
acknowledgement of the paper you never submitted, and then you complain that
such acknowledgement will make a statement that EWG has made some apparently
procedural mistake. Well, to be sure, I'm not going to modify issue 30, then.

What exactly is "your claim"? Unfair treatment? If you have complaints
about the EWG
agenda and/or the time allocated for the discussion of your proposal,
and the handling
of your proposal, take them to the EWG chair. I do see further claims
such as "no technical
arguments", but that seems like a bold claim, since I find it unlikely
that the guidance
given for your proposal was purely formed from non-technical reasons.

Zhihao Yuan

unread,
Jul 22, 2014, 11:51:04 AM7/22/14
to std-pr...@isocpp.org
On Tue, Jul 22, 2014 at 11:14 AM, Ville Voutilainen <ville.vo...@gmail.com> wrote:
> Why does the website does not say that one has to be NB member in
> order to be heard?

Considering you are logical, you won't take a sufficient condition as
a necessary condition, right?
 
What is the purpose of the std-proposals mailing list?
> How are people supposed to be discussing them?

This forum provides a way to solicit feedback on proposals from random
individuals
before taking such proposals to the committee. This forum is not part
of the official
N-paper submission process in any way.

Send paper to lwgc...@gmail.com is *the* official process
(http://open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3370.html#Submission-procedures),
even it's a language paper.  Ville, I think we need to make this
the first time people only publish paper on std-proposals@

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

Nevin Liber

unread,
Jul 22, 2014, 11:52:17 AM7/22/14
to std-pr...@isocpp.org
On 22 July 2014 10:14, Ville Voutilainen <ville.vo...@gmail.com> wrote:

>> Well, it's unreasonable to expect people to have read a paper that did not
>> appear in the pre-meeting mailing.
>>
> It is equally unreasonable then for people who have not read it to pass
> judgment at lunchtime and the following day delegate issues strongly related

If that's a concern for you, make sure people have time to read your
paper. If you
solicit feedback at the risk of people not having read your paper,
you'll get what
you'll get.

+1.  Given that we have a huge amount of work to do, and only a tiny amount of time and a tiny number of people to do it with, priority is given to those papers that are in a mailing and have a presenter to champion it.  There are typically 100+ new papers (not to mention that earlier ones occasionally resurface) in the mailings for the committee to cover in a week, it is unreasonable to expect people to read a paper that was not in a mailing.  One exception is sometimes papers get written at the meeting to address an issue which came up at the meeting, and that will usually get priority as well.  We do try and accommodate anyone that is present, but if you want anything other than "first impressions", get your paper into a mailing and have someone present it.
 
> to it (like EWG #30) to sponsored insiders. The "fixed size parameter packs"

"Sponsored insiders" as in volunteers willing to work further on the idea?

I really have no idea what this insider vs. outsider nonsense is all about.

> without underlining these facts? As far as "unsponsored outsiders", meaning
> people not working for particular employees and companies, it would be
> interesting to also study who "votes" for what, when, and for whom.

If you want to join the committee and spend your time doing that, it'll be your time to waste.  I'd rather spend my time making a better language.

>> I'm unaware of such "author rights".

There is the INCITS copyright policy at <http://www.incits.org/dotAsset/d1ac06e9-afdf-42a9-adf4-9f96f2fd4572.pdf>, which specifically says "without any duty to compensate or account to the original copyright owners".
--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com(847) 691-1404

George Makrydakis

unread,
Jul 22, 2014, 11:53:24 AM7/22/14
to std-pr...@isocpp.org, Ville Voutilainen
Repeating from reply-to myself...

For your information, unfortunate posts like the one by Botond Ballo classified it as "accepted proposal". You guys obviously do not talk to each other and thus have problems of mutual understanding.

Since when parameter pack manipulation through language level features is based on non-technical grounds? Ludicrous and quite compromising the value of anything the EWG says from now on.

It is not a problem if you do not modify issue #30 it but you will be submitting yourself to another non-sequitur which invalidates any authority or bodacious claim to "who is better who is worse". Fixed size packs proposal passed EWG "expert review" while having ambiguous syntax that the author is to revise and not even covering the issue of individual access in his original "draft"; that speaks volumes about the EWG's expertise or tendency to succumb to unknown "factors". My incomplete draft was formed from purely technical arguments as to why pack annotation would resolve source code boilerplate generation problems, buggy-prone recursive instantiations and all the rest.

You allowed at least 2 different N-less papers not in the pre-meeting mailing list to pass but treated unequally. And you are asking me what your problem is? I quote again what your problem is that no ad-hominem will resolve:

"The EWG gave a language feature recommendation the next day for practically same thing and that is a factual blunder so unfortunate you cannot defend; that is why you are to partially amend your writing of the facts. This kind of makes the motivation of the initial "library recommendation" questionable and is your actual unsolvable problem."

Not accepting to amend your transcription? You have just lost the argument, yet again by proving that you have a very unsolvable problem with this by going into non-sequitur; this is not just unusual for Ville, it is ludicrously uncommon for the EWG to have such a vulnerability. But then again, it cannot justify what the EWG did (or should I say, some members). I know that I will be ferociously "attacked" for anything incomplete, you will ignore the incoming paper and of course reject it without providing technical reasoning, yet again. That's when it will start biting you and the EWG practices. The paper will be completed Ville, this is not irc and you are losing your temper. Do not expect me to follow you.

The proper course of action of an authoritative leader (does he exist? I wonder) would be to intervene and resolve the situation between parties in conflict. But in your overconfident behavior and onerous position, you are trying to emotionally engineer your way out of this. It will not work because ... the paper will be completed knowingly that people will more or less treat it as a conceptual supermarket. And it will be a permanent stigma to a rather less than bright "mistake" of the EWG.

Keiserens nye Klæder still applies; the little kid exists and you cannot do anything about it, including changing facts that have already taken place. Let's just wait for my final paper, will we. It is technically my own work after all. Remember to respect it when time comes.

George

Ville Voutilainen

unread,
Jul 22, 2014, 12:10:52 PM7/22/14
to George Makrydakis, std-pr...@isocpp.org
On 22 July 2014 18:54, George Makrydakis <irreq...@gmail.com> wrote:
> What exactly is "your claim"? Unfair treatment? If you have complaints
> about the EWG
> agenda and/or the time allocated for the discussion of your proposal,
> and the handling
> of your proposal, take them to the EWG chair. I do see further claims
> such as "no technical
> arguments", but that seems like a bold claim, since I find it unlikely
> that the guidance
> given for your proposal was purely formed from non-technical reasons.
>
> Repeating from reply-to myself...
>
> For your information, unfortunate posts like the one by Botond Ballo
> classified it as "accepted proposal". You guys obviously do not talk to each
> other and thus have problems of mutual understanding.

I know what an accepted proposal is. It's a proposal that gets onto formal
motions of a meeting and gets voted into a working draft. What other people
report is beyond my control.

>
> Since when parameter pack manipulation through language level features is
> based on non-technical grounds? Ludicrous and quite compromising the value
> of anything the EWG says from now on.

I have no idea what this is referring to.

>
> It is not a problem if you do not modify issue #30 it but you will be

The only modification I concerned was referring to the non-N-numbered proposals.
But perhaps people would read too much into it, since there are these statements
as to how it constitutes proof of what-ever.

> submitting yourself to another non-sequitur which invalidates any authority
> or bodacious claim to "who is better who is worse". Fixed size packs

I wasn't aware there was such a discussion ongoing.

> proposal passed EWG "expert review" while having ambiguous syntax that the
> author is to revise and not even covering the issue of individual access in
> his original "draft"; that speaks volumes about the EWG's expertise or
> tendency to succumb to unknown "factors". My incomplete draft was formed
> from purely technical arguments as to why pack annotation would resolve
> source code boilerplate generation problems, buggy-prone recursive
> instantiations and all the rest.

Well, that doesn't seem to have been obvious to the set of people outside
yourself.

>
> You allowed at least 2 different N-less papers not in the pre-meeting
> mailing list to pass but treated unequally. And you are asking me what your
> problem is? I quote again what your problem is that no ad-hominem will
> resolve:
>
> "The EWG gave a language feature recommendation the next day for practically
> same thing and that is a factual blunder so unfortunate you cannot defend;
> that is why you are to partially amend your writing of the facts. This kind
> of makes the motivation of the initial "library recommendation" questionable
> and is your actual unsolvable problem."

As I replied privately, I fail to see how it's "for practically same
thing". It seems to me
that EWG was for
a language feature for a limited set of the functionality, and
recommended a library
solution for the more elaborate parts.

>
> Not accepting to amend your transcription? You have just lost the argument,
> yet again by proving that you have a very unsolvable problem with this by
> going into non-sequitur; this is not just unusual for Ville, it is

I don't know what transcription you're talking about. If it refers to
the EWG issues
list, that list includes a track record of papers and issue
submissions. If you have
an issue to submit, I will add it to the list. If you have a published
N-paper that is not
tracked by the list, I can certainly add the paper. I fail to see
which part of any of
this is ad-hominem, and I certainly do not have the capability to keep
on guessing
what you want and what would not be a non-sequitur to you.

> ludicrously uncommon for the EWG to have such a vulnerability. But then
> again, it cannot justify what the EWG did (or should I say, some members). I
> know that I will be ferociously "attacked" for anything incomplete, you will
> ignore the incoming paper and of course reject it without providing
> technical reasoning, yet again. That's when it will start biting you and the
> EWG practices. The paper will be completed Ville, this is not irc and you
> are losing your temper. Do not expect me to follow you.

I'm losing my temper? You "know" that you will be "attacked" for anything
incomplete, you know that this mystical "you" will ignore the incoming paper..
I don't know what sort of illusions you labor under, and I certainly do not know
what these statements are based on.

>
> The proper course of action of an authoritative leader (does he exist? I
> wonder) would be to intervene and resolve the situation between parties in
> conflict. But in your overconfident behavior and onerous position, you are
> trying to emotionally engineer your way out of this. It will not work
> because ... the paper will be completed knowingly that people will more or
> less treat it as a conceptual supermarket. And it will be a permanent stigma
> to a rather less than bright "mistake" of the EWG.

I have thus far been pointing out mistakes in your claims, which seem to be
not quite undisputed facts, as you like to claim them to be. You make quite
a lot of bold claims without much evidence to support them, including
insinuations
of some wrong-doing by the EWG.

George Makrydakis

unread,
Jul 22, 2014, 12:18:11 PM7/22/14
to std-pr...@isocpp.org

On 07/22/2014 06:50 PM, Zhihao Yuan wrote:
On Tue, Jul 22, 2014 at 11:14 AM, Ville Voutilainen <ville.vo...@gmail.com> wrote:
> Why does the website does not say that one has to be NB member in
> order to be heard?

Considering you are logical, you won't take a sufficient condition as
a necessary condition, right?
 

Considering that I was invited and motivated by Ville and my country has no NB yet, this is another attempt at changing the argument over what the EWG has done to itself: taking an idea without actually really evaluating it and redelegating it to other members. I would not have raised such a concern if issue #30 did not exist anymore. I am thus entitled as an author, to persistently show your non-sequitur since you are obviously not going to be taking into account my work once it is finished.

If you are all so adamant about procedure, why didn't you follow it and allowed presentation? Why did you treat two different N-less papers unequally and now try to avoid replying to this fact? No pre-meeting email for either, no N-number, no company origin.

Will I be given an N-number or not once I submit this in its final form? Plain and fair. Prior work exists now. Emotionally engineering your way out of this, will not work. Let's play it fair for everybody guys, because you know some people haven't. Most likely due to lack of diligence.


George

Ville Voutilainen

unread,
Jul 22, 2014, 12:21:31 PM7/22/14
to std-pr...@isocpp.org
On 22 July 2014 19:19, George Makrydakis <irreq...@gmail.com> wrote:
> Considering that I was invited and motivated by Ville and my country has no
> NB yet, this is another attempt at changing the argument over what the EWG
> has done to itself: taking an idea without actually really evaluating it and
> redelegating it to other members. I would not have raised such a concern if

Which part of that is problematic? The claim "without actually really
evaluating it"
is a very biased statement with which not everyone agrees. As to redelegating
it to other members, EWG has every right to invite people to do further work.

> If you are all so adamant about procedure, why didn't you follow it and
> allowed presentation? Why did you treat two different N-less papers
> unequally and now try to avoid replying to this fact? No pre-meeting email
> for either, no N-number, no company origin.

Which part of the treatment exactly was unequal? The end result?

> Will I be given an N-number or not once I submit this in its final form?

Certainly.

> Plain and fair. Prior work exists now. Emotionally engineering your way out
> of this, will not work. Let's play it fair for everybody guys, because you
> know some people haven't. Most likely due to lack of diligence.


I fail to grasp what you mean by "emotional engineering", and I state
that the claims of unfairness are bold.

George Makrydakis

unread,
Jul 22, 2014, 12:37:07 PM7/22/14
to std-pr...@isocpp.org

On 07/22/2014 06:51 PM, Nevin Liber wrote:
If that's a concern for you, make sure people have time to read your
paper. If you
solicit feedback at the risk of people not having read your paper,
you'll get what
you'll get.

+1.  Given that we have a huge amount of work to do, and only a tiny amount of time and a tiny number of people to do it with, priority is given to those papers that are in a mailing and have a presenter to champion it.  There are typically 100+ new papers (not to mention that earlier ones occasionally resurface) in the mailings for the committee to cover in a week, it is unreasonable to expect people to read a paper that was not in a mailing.  One exception is sometimes papers get written at the meeting to address an issue which came up at the meeting, and that will usually get priority as well.  We do try and accommodate anyone that is present, but if you want anything other than "first impressions", get your paper into a mailing and have someone present it.
Infact, you are the one who uploaded my paper to the wiki a few minutes before the "presentation" took place. I thank you for that. I managed to come Wed. because that is when I could. I asked for time and I was given the lunch spot after two days with 4 hours of sleep. Seeing my work getting delegated to other people when I have already stated in the presentation itself that it covers a series of EWG issues, was kind of awkward for the respect of my own time first since I was invited and motivated to go through this ordeal. It would have not been a problem if otherwise. This is a fact.


 
> to it (like EWG #30) to sponsored insiders. The "fixed size parameter packs"

"Sponsored insiders" as in volunteers willing to work further on the idea?

Sponsored insiders who are part of colleagues in companies who easily promote them by voting and promoting them. You people are a pretty close group with your own internal friends and enemies. That is clear.

I came alone without knowing anybody but Ville who obviously had a lot of things to think about. Now we all know each other. I am an original volunteer wanting to work on issue #30 because my work addresses it directly. Once it is completed, you are welcome to disprove its claims and I have absolutely no problem with that.



I really have no idea what this insider vs. outsider nonsense is all about.

> without underlining these facts? As far as "unsponsored outsiders", meaning
> people not working for particular employees and companies, it would be
> interesting to also study who "votes" for what, when, and for whom.

If you want to join the committee and spend your time doing that, it'll be your time to waste.  I'd rather spend my time making a better language.

>> I'm unaware of such "author rights".

There is the INCITS copyright policy at <http://www.incits.org/dotAsset/d1ac06e9-afdf-42a9-adf4-9f96f2fd4572.pdf>, which specifically says "without any duty to compensate or account to the original copyright owners".

This is not about the INCITS copyright policy and compensation because I am not minimally interested in this at all. An author taking "something else" from "somebody else" and presenting it as his own without due reference, makes him personally liable. Not the INCITS. The EWG in its haste, created the problem ignoring what I said; it was lunch hour after all. I did not have a problem with that. What the EWG will have problems with, is that the next day it delegated the essence of it to other parties.

All I am asking, is an N number for when the paper is to be completed since Saturday morning I was instructed to do so. This is not even in the wiki. Why? I am entitled to voice my concern. And you all heard that the process of such things is problematic from Herb Sutter during the initial "presentation".

I am not the guilty party here. I came into your group offering my time for free and was motivated to do so. I did not just wake up one morning to make a cumbersome trip. And you have understood that I do not lack the skills or the will for pursuing this.

Is this how you behave to newcomers?

Anyway, you mr Liber are among the kindest people there and I hope that you do not take this personally.










George Makrydakis

unread,
Jul 22, 2014, 12:58:04 PM7/22/14
to std-pr...@isocpp.org

On 07/22/2014 07:21 PM, Ville Voutilainen wrote:
Which part of that is problematic? The claim "without actually really
evaluating it"
is a very biased statement with which not everyone agrees. As to redelegating
it to other members, EWG has every right to invite people to do further work.

Does it have every right to usurp other people's time and dedication? I already said that I will continue work with this. Vandevoorde saying "it would stress the compiler" for the next day expressing interest (according to your transcription) to do index-based and range-based access on parameter packs seems kind of awkward for me to accept given the enormous respect I have for that person.



If you are all so adamant about procedure, why didn't you follow it and
allowed presentation? Why did you treat two different N-less papers
unequally and now try to avoid replying to this fact? No pre-meeting email
for either, no N-number, no company origin.
Which part of the treatment exactly was unequal? The end result?

"The EWG gave a language feature recommendation the next day for practically same thing and that is a factual blunder so unfortunate you cannot defend; that is why you are to partially amend your writing of the facts. This kind of makes the motivation of the initial "library recommendation" questionable and is your actual unsolvable problem."

That is not a result; it is your problem and you are avoiding to address it.


Will I be given an N-number or not once I submit this in its final form?
Certainly.
You should then revise your transcript containing the final recommendation that took place Saturday Morning about me working on this in the end. Vandevoorde should be made aware, as well as Bos who offered to do things he did not even have in his own draft. I have no problems working with anybody. Can they say the same, on technical grounds? If they can, I am always all ears and eyes. After all, my work based on my ideas is public in a git repository and not developed behind anybody's back.


Plain and fair. Prior work exists now. Emotionally engineering your way out
of this, will not work. Let's play it fair for everybody guys, because you
know some people haven't. Most likely due to lack of diligence.

I fail to grasp what you mean by "emotional engineering", and I state
that the claims of unfairness are bold.

If you fail to grasp this, then I state it clearly: you are not angering your interlocutor out of the argument, this is not an irc channel: the EWG messed this up, the EWG has to clean it up.

I will be persistent in proving this. It matters little if you accept the "proposal" or not, if you are eventually to adopt its essence. You state whatever you please, but that does not mean that you are also able to proving your statements as true. Disliking an idea or a person, is not enough. You have to prove them wrong. And so far, the only wrong-doer is the EWG.

Remember, you personally motivated and invited. If you cannot trust an C++ standard committee secretary, who can you trust? I can accept the no guarantees because I did not come about with a proposal, but with an idea and a draft as well as a chance to meet some people I once had respect for.  I would have just walked out peacefully if EWG issue #30 wasn't treated as such in relation to my incomplete work given the ordeal that I put myself for coming there.

These are not claims of unfairness, the argument is that the EWG messed up - whether accidentally or whatever, it will be proven in time. Keiserens nye Klæder still applies; the little kid exists.

George

Ville Voutilainen

unread,
Jul 22, 2014, 1:16:39 PM7/22/14
to std-pr...@isocpp.org
On 22 July 2014 19:59, George Makrydakis <irreq...@gmail.com> wrote:
>
> On 07/22/2014 07:21 PM, Ville Voutilainen wrote:
>
> Which part of that is problematic? The claim "without actually really
> evaluating it"
> is a very biased statement with which not everyone agrees. As to
> redelegating
> it to other members, EWG has every right to invite people to do further
> work.
>
>
> Does it have every right to usurp other people's time and dedication? I
> already said that I will continue work with this. Vandevoorde saying "it
> would stress the compiler" for the next day expressing interest (according
> to your transcription) to do index-based and range-based access on parameter
> packs seems kind of awkward for me to accept given the enormous respect I
> have for that person.

Just because Daveed expressed interest in working in the are doesn't constitute
"usurping" your time and dedication. He's at perfect liberty to work on whatever
he wishes. You may want to work together with him, but you're not forced to.

> If you are all so adamant about procedure, why didn't you follow it and
> allowed presentation? Why did you treat two different N-less papers
> unequally and now try to avoid replying to this fact? No pre-meeting email
> for either, no N-number, no company origin.
>
> Which part of the treatment exactly was unequal? The end result?
>
>
> "The EWG gave a language feature recommendation the next day for practically
> same thing and that is a factual blunder so unfortunate you cannot defend;
> that is why you are to partially amend your writing of the facts. This kind
> of makes the motivation of the initial "library recommendation" questionable
> and is your actual unsolvable problem."
>
> That is not a result; it is your problem and you are avoiding to address it.

To repeat myself: "As I replied privately, I fail to see how it's "for
practically same
thing". It seems to me
that EWG was for
a language feature for a limited set of the functionality, and
recommended a library
solution for the more elaborate parts."

> Will I be given an N-number or not once I submit this in its final form?
>
> Certainly.
>
> You should then revise your transcript containing the final recommendation
> that took place Saturday Morning about me working on this in the end.

Perhaps you should be a bit careful before making various claims. The minutes
on the EWG wiki for that Saturday discussion are not mine, they are
James Dennett's.
I'm not going to go there and edit them adding such record of
discussion, because
I'm unaware of whether such discussion took place on Saturday morning.

> Vandevoorde should be made aware, as well as Bos who offered to do things he
> did not even have in his own draft. I have no problems working with anybody.

Well, then by all means contact Daveed and Maurice and make them aware of what
you want to make them aware of.

> Can they say the same, on technical grounds? If they can, I am always all

Ask them.

> I will be persistent in proving this. It matters little if you accept the
> "proposal" or not, if you are eventually to adopt its essence. You state
> whatever you please, but that does not mean that you are also able to
> proving your statements as true. Disliking an idea or a person, is not
> enough. You have to prove them wrong. And so far, the only wrong-doer is the
> EWG.

I frankly fail to see what the wrong-doing by EWG consists of.

> Remember, you personally motivated and invited. If you cannot trust an C++

Indeed I did.

> standard committee secretary, who can you trust? I can accept the no

Uh huh. I don't know what trust I have betrayed, and how.

George Makrydakis

unread,
Jul 22, 2014, 1:27:47 PM7/22/14
to Ville Voutilainen, std-pr...@isocpp.org

On 07/22/2014 07:10 PM, Ville Voutilainen wrote:
I know what an accepted proposal is. It's a proposal that gets onto formal
motions of a meeting and gets voted into a working draft. What other people
report is beyond my control.
Did not imply that it was, irrelevant to any argument we have already discussed this.
Since when parameter pack manipulation through language level features is
based on non-technical grounds? Ludicrous and quite compromising the value
of anything the EWG says from now on.
I have no idea what this is referring to.

EWG issue #30. We can go on eternally. You are a C++ expert and you know that pack manipulation refers to the essence of what Abrahams asks in issue #30. Isn't that "manipulating packs"  if you take N, access at N etc ?

It is not a problem if you do not modify issue #30 it but you will be
Then give me the luxury of notifying people that there is this individual who is working on it because he is up to something. Delegating it elsewhere was a non-sequitur. The work was not disproven for its worth even in incomplete. I am still working on it. And it would make me "shut up" pointing to what your problem is:


"The EWG gave a language feature recommendation the next day for practically same thing and that is a factual blunder so unfortunate you cannot defend; that is why you are to partially amend your writing of the facts. This kind of makes the motivation of the initial "library recommendation" questionable and is your actual unsolvable problem."

You once said you will, you then say you won't. The problem still stays and kind of becomes worse. Didn't that meeting in Saturday take place?



submitting yourself to another non-sequitur which invalidates any authority
or bodacious claim to "who is better who is worse". Fixed size packs
I wasn't aware there was such a discussion ongoing.

proposal passed EWG "expert review" while having ambiguous syntax that the
author is to revise and not even covering the issue of individual access in
his original "draft"; that speaks volumes about the EWG's expertise or
tendency to succumb to unknown "factors". My incomplete draft was formed
from purely technical arguments as to why pack annotation would resolve
source code boilerplate generation problems, buggy-prone recursive
instantiations and all the rest.
Well, that doesn't seem to have been obvious to the set of people outside
yourself.
Not my problem if they have not read or followed the presentation. Already proven otherwise elsewhere, getting back into this loop will not help the discourse. You are making an ostentatious claim that is forced into existing without proof. But we are still friends because I fully understand your position and I leave it there. Ten million people can have consensus on something wrong; it will still be wrong regardless of their consensus; the handling of this case was far from being canonical or a stellar example of EWG deliberations. Remember when some people thought the earth was a flat disk or that the sun revolved around the earth?


You allowed at least 2 different N-less papers not in the pre-meeting
mailing list to pass but treated unequally. And you are asking me what your
problem is? I quote again what your problem is that no ad-hominem will
resolve:

"The EWG gave a language feature recommendation the next day for practically
same thing and that is a factual blunder so unfortunate you cannot defend;
that is why you are to partially amend your writing of the facts. This kind
of makes the motivation of the initial "library recommendation" questionable
and is your actual unsolvable problem."
As I replied privately, I fail to see how it's "for practically same
thing". It seems to me
that EWG was for
a language feature for a limited set of the functionality, and
recommended a library
solution for the more elaborate parts.
No, they gave a full library recommendation that was unsubstantiated. The problem was with what happened the day after. My emails to this mailing list prove that. Sorry I missed your private email.


Not accepting to amend your transcription? You have just lost the argument,
yet again by proving that you have a very unsolvable problem with this by
going into non-sequitur; this is not just unusual for Ville, it is
I don't know what transcription you're talking about. If it refers to
the EWG issues
list, that list includes a track record of papers and issue
submissions. If you have
an issue to submit, I will add it to the list. If you have a published
N-paper that is not
tracked by the list, I can certainly add the paper. I fail to see
which part of any of
this is ad-hominem, and I certainly do not have the capability to keep
on guessing
what you want and what would not be a non-sequitur to you.

If I have published a paper? I sent an incomplete draft in the std-proposals mailing list. I contacted you several times and wasn't indicated another course. Nevin Liber uploaded a version of it in the wiki. I think you are aware of these things already. Correctness implies that people should be informed that there is also somebody else who presented an idea and wished to work on it, not just Vandevoorde who expressed fears of "making the compiler more complex" for the next day to volunteer to work on issue #30. Fears of making templates too complicated are practically thrown out of the window if you tackle issue #30. You were present in the Saturday Morning EWG meeting. You yourself allowed me to voice my concern and allowed the discussion to occur.

Where is that discussion? Wasn't I given clear way of proceeding with this? And then I read posts like the one from Botond which are utterly untrue and quite... well, whatever. I played by your rules guys, now I am going to hold you to them.

Let me be clear: I do not want an N-number now, but I will request it once I finish. Incomplete proposals should not get N-numbers nor "fast-track" access (not my proposal's case). But I digress But that does not mean that they should not be discussed. Do remember that although I am a newcomer to your tight inner circle and wish to not be a part of it outside technical contribution. My life is not going to get any better or worse by giving time to this; it is just an important and joyful activity for yours truly.

I only knew you and you alone. Understanding your position now, I will not go further; you are not responsible so you are not the problem.



ludicrously uncommon for the EWG to have such a vulnerability. But then
again, it cannot justify what the EWG did (or should I say, some members). I
know that I will be ferociously "attacked" for anything incomplete, you will
ignore the incoming paper and of course reject it without providing
technical reasoning, yet again. That's when it will start biting you and the
EWG practices. The paper will be completed Ville, this is not irc and you
are losing your temper. Do not expect me to follow you.
I'm losing my temper? You "know" that you will be "attacked" for anything
incomplete, you know that this mystical "you" will ignore the incoming paper..
I don't know what sort of illusions you labor under, and I certainly do not know
what these statements are based on.
I do not have problems being attacked on solid technical grounds on something complete. Unfortunately only hillariously incongruent arguments were given in view of EWG #30 treatment the following day. That is your problem, not me. I am just making sure that you are to remember that it is your problem from now on.


The proper course of action of an authoritative leader (does he exist? I
wonder) would be to intervene and resolve the situation between parties in
conflict. But in your overconfident behavior and onerous position, you are
trying to emotionally engineer your way out of this. It will not work
because ... the paper will be completed knowingly that people will more or
less treat it as a conceptual supermarket. And it will be a permanent stigma
to a rather less than bright "mistake" of the EWG.
I have thus far been pointing out mistakes in your claims, which seem to be
not quite undisputed facts, as you like to claim them to be. You make quite
a lot of bold claims without much evidence to support them, including
insinuations
of some wrong-doing by the EWG.

"The EWG gave a language feature recommendation the next day for practically same thing and that is a factual blunder so unfortunate you cannot defend; that is why you are to partially amend your writing of the facts. This kind of makes the motivation of the initial "library recommendation" questionable and is your actual unsolvable problem."


Index and range based access was in the draft. Also in the slides. Also discussed. Also referred to. You cannot change that fact but submit to how EWG issue #30  was stated.

Keiserens nye Klæder still applies; the little kid exists.

George




Ville Voutilainen

unread,
Jul 22, 2014, 1:54:57 PM7/22/14
to George Makrydakis, std-pr...@isocpp.org
On 22 July 2014 20:28, George Makrydakis <irreq...@gmail.com> wrote:
> If I have published a paper? I sent an incomplete draft in the std-proposals
> mailing list. I contacted you several times and wasn't indicated another
> course. Nevin Liber uploaded a version of it in the wiki. I think you are
> aware of these things already. Correctness implies that people should be
> informed that there is also somebody else who presented an idea and wished
> to work on it, not just Vandevoorde who expressed fears of "making the
> compiler more complex" for the next day to volunteer to work on issue #30.
> Fears of making templates too complicated are practically thrown out of the
> window if you tackle issue #30. You were present in the Saturday Morning EWG
> meeting. You yourself allowed me to voice my concern and allowed the
> discussion to occur.


I'll make this really simple for you: are you asking an amendmend to EWG 30 that
simply states that your (and Maurice's) (unfinished) work is related
to that issue?

Ville Voutilainen

unread,
Jul 22, 2014, 1:59:48 PM7/22/14
to George Makrydakis, std-pr...@isocpp.org
Follow-up question: do you want a separate EWG issue to be opened to cover for
the facility to be able to define "sized" parameter packs, or do you
want to wait until
an EWG issue is opened automatically for your paper?

George Makrydakis

unread,
Jul 22, 2014, 2:50:00 PM7/22/14
to Ville Voutilainen, std-pr...@isocpp.org

On 07/22/2014 08:54 PM, Ville Voutilainen wrote:
>
> I'll make this really simple for you: are you asking an amendmend to EWG 30 that
> simply states that your (and Maurice's) (unfinished) work is related
> to that issue?
Really easy for you as well: Does Maurice's proposal have anything to do
with issue #30 (hint: it does not)? He did not have index-based or
range-based access and he was even against it when you suggested we
talked about it first in order to avoid "competing proposals". Will I be
working against Vandevoorde whom Maurice "offered" to help for something
he was clearly against to only pick it up later on?

The EWG mailing list is closed to the public from what I know. I do not
have a problem if they wish me to continue with this with whom they
choose. Stroustrup himself said "whoever wants to help" from what I
heard, which means that the problem is easily solved even if he is
scared to death of template meta-programming. If they keep it technical,
I will keep it technical. My work and code is public on github either
way and will continue to be so. Is there a real technical reason not to
work together given that yours truly already did work on this?

Hear them first, since it is them - you excluded, despite I understand
your position - who created this mess due to their haste. When I talked
to Doug Gregor and Daveed Vandevoorde they were understanding. A month
later nothing happened and then I see the "Botond Ballo trip report".
Everybody is busy and I am even more, but I am obviously not letting
this one go without clearing it up. I am going to deal with this on a
daily basis with specific time allocated for it, compiler-wise as well.

Everybody wins if the people who started this, simply accept to exchange
views and not play in different rooms. Extending parameter packs is not
a problem as easy as it seems and it is far too easy to mess it up with
"let's see what this syntax does". Playing it otherwise is playing with
fire. Perhaps this is a thing that requires a SG than a single
individual, since parameter packs will have lots of proposals in the
near future anyway. Let's not play this the Prisoner's Dilemma way.
Let's give the damn king some clothes at last.

I'll be waiting.

George


Ville Voutilainen

unread,
Jul 22, 2014, 3:00:19 PM7/22/14
to George Makrydakis, std-pr...@isocpp.org
On 22 July 2014 21:51, George Makrydakis <irreq...@gmail.com> wrote:
>
> On 07/22/2014 08:54 PM, Ville Voutilainen wrote:
>>
>>
>> I'll make this really simple for you: are you asking an amendmend to EWG
>> 30 that
>> simply states that your (and Maurice's) (unfinished) work is related
>> to that issue?
>
> Really easy for you as well: Does Maurice's proposal have anything to do
> with issue #30 (hint: it does not)? He did not have index-based or

If it does, it has very little to do with it, so perhaps it shouldn't
be mentioned as
related. The question about your work still stands.

> range-based access and he was even against it when you suggested we talked
> about it first in order to avoid "competing proposals". Will I be working
> against Vandevoorde whom Maurice "offered" to help for something he was
> clearly against to only pick it up later on?

I don't know; ask Daveed.

>
> The EWG mailing list is closed to the public from what I know. I do not have

For what it's worth, none of this potential work has been discussed on the EWG
mailing list as far as I can see.

George Makrydakis

unread,
Jul 22, 2014, 3:08:46 PM7/22/14
to Ville Voutilainen, std-pr...@isocpp.org

On 07/22/2014 10:00 PM, Ville Voutilainen wrote:
> On 22 July 2014 21:51, George Makrydakis <irreq...@gmail.com> wrote:
>> On 07/22/2014 08:54 PM, Ville Voutilainen wrote:
>>>
>>> I'll make this really simple for you: are you asking an amendmend to EWG
>>> 30 that
>>> simply states that your (and Maurice's) (unfinished) work is related
>>> to that issue?
>> Really easy for you as well: Does Maurice's proposal have anything to do
>> with issue #30 (hint: it does not)? He did not have index-based or
> If it does, it has very little to do with it, so perhaps it shouldn't
> be mentioned as
> related. The question about your work still stands.
It is not related to EWG#30, but it will be affected by it in the end.
Mine already was about EWG#30 and it will get completed.
>
>> range-based access and he was even against it when you suggested we talked
>> about it first in order to avoid "competing proposals". Will I be working
>> against Vandevoorde whom Maurice "offered" to help for something he was
>> clearly against to only pick it up later on?
> I don't know; ask Daveed.
Obviously. But he is in the EWG mailing list as Doug Gregor is and they
both said that they would be open to this. But nothing happened so I
guess it kind of got lost in the wind.
>
>> The EWG mailing list is closed to the public from what I know. I do not have
> For what it's worth, none of this potential work has been discussed on the EWG
> mailing list as far as I can see.
Can you please forward my previous email to the EWG as a request? This
entire thread is about this issue anyway. Nobody is in a hurry since
everybody is busy. Work continues.

Thank you.

George

Ville Voutilainen

unread,
Jul 22, 2014, 3:14:48 PM7/22/14
to George Makrydakis, std-pr...@isocpp.org
On 22 July 2014 22:09, George Makrydakis <irreq...@gmail.com> wrote:
>>>> I'll make this really simple for you: are you asking an amendmend to EWG
>>>> 30 that
>>>> simply states that your (and Maurice's) (unfinished) work is related
>>>> to that issue?
>>> Really easy for you as well: Does Maurice's proposal have anything to do
>>> with issue #30 (hint: it does not)? He did not have index-based or
>> If it does, it has very little to do with it, so perhaps it shouldn't
>> be mentioned as
>> related. The question about your work still stands.
> It is not related to EWG#30, but it will be affected by it in the end. Mine
> already was about EWG#30 and it will get completed.

Is that a "yes" or "no"?

>>> range-based access and he was even against it when you suggested we
>>> talked
>>> about it first in order to avoid "competing proposals". Will I be working
>>> against Vandevoorde whom Maurice "offered" to help for something he was
>>> clearly against to only pick it up later on?
>> I don't know; ask Daveed.
> Obviously. But he is in the EWG mailing list as Doug Gregor is and they both
> said that they would be open to this. But nothing happened so I guess it
> kind of got lost in the wind.

Perhaps you should contact them, then.

>> For what it's worth, none of this potential work has been discussed on the
>> EWG
>> mailing list as far as I can see.
> Can you please forward my previous email to the EWG as a request? This

You mean the email that starts this thread?

George Makrydakis

unread,
Jul 22, 2014, 5:26:57 PM7/22/14
to Ville Voutilainen, std-pr...@isocpp.org
Just this one:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qIs0Ws7WdwA/rexm9tMcT6QJ
because I am certain they will get the gist of it. Everybody seemed
quite reasonable when they actually started listening. I do not have a
way of addressing the EWG through the mailing lists. They are not public
from what I know.

Thanks

On 07/22/2014 10:14 PM, Ville Voutilainen wrote:
> On 22 July 2014 22:09, George Makrydakis <irreq...@gmail.com> wrote:
>>>>> I'll make this really simple for you: are you asking an amendmend to EWG
>>>>> 30 that
>>>>> simply states that your (and Maurice's) (unfinished) work is related
>>>>> to that issue?
>>>> Really easy for you as well: Does Maurice's proposal have anything to do
>>>> with issue #30 (hint: it does not)? He did not have index-based or
>>> If it does, it has very little to do with it, so perhaps it shouldn't
>>> be mentioned as
>>> related. The question about your work still stands.
>> It is not related to EWG#30, but it will be affected by it in the end. Mine
>> already was about EWG#30 and it will get completed.
> Is that a "yes" or "no"?
Am I completing the paper? Yes. Would I like to help if allowed someone
else? Never was a problem if we all played in the same room as I say.
Would I like EWG#30 to reflect this? After all the trouble I that it got
me into, yes.

George

George Makrydakis

unread,
Jul 22, 2014, 5:32:21 PM7/22/14
to Ville Voutilainen, std-pr...@isocpp.org

On 07/22/2014 08:59 PM, Ville Voutilainen wrote:
> Follow-up question: do you want a separate EWG issue to be opened to cover for
> the facility to be able to define "sized" parameter packs, or do you
> want to wait until
> an EWG issue is opened automatically for your paper?
My work is obviously related to EWG#30 in the end because it is asking
for index and range based access as well as extracting multiple, ordered
types from a pack in one blow. That is the first thing annotated
template parameter packs were designed for. If I see something spawning
out of it towards completion, I will ask for guidance through this
mailing list. Never wanted to start any of this in any other way.

Thanks,

George

botond...@gmail.com

unread,
Jul 23, 2014, 12:54:39 AM7/23/14
to std-pr...@isocpp.org, bot...@mozilla.com

On Tuesday, July 22, 2014 6:56:18 AM UTC-4, George Makrydakis wrote:
You really think that expanding packs as expressions (which is an infinitely useful thing) in the context of an unrelated proposal is not "complicating the language" as well?

My post is less about what I think, and more about reporting points that others have made. I mentioned "complicating the language" because that is one of the points I heard people bring up during the discussion of your proposal. The idea of expanding packs as expressions wasn't written up and discussed in any detail at this meeting; if it will be at a future meeting, and people mention "complicating the language" in the discussion, I will mention that too.

It was said by an EWG member acting as an arbiter in the first part of the last Saturday EWG morning meeting, after my own raise of concern, that an honest resolution would be to promote a final version of the document. I also did not see this mentioned in the wiki, or your trip report. This and the fact that it initially got a "library recommendation", means that there was no rejection in either session. Your classification is therefore defenseless.

As I explained in my response to your comment on my blog post, my rationale for listing your proposal under "rejected" was that it was listed so on the slide deck in EWG's report to the full committee in plenary.

That said - I recognize that, since this paper was not in the pre-Rapperswil mailing and many attendees did not get a chance to read it in advance, the discussion of it was less comprehensive than for other proposals, and therefore the outcome of such discussion should not be taken for granted. I amended by blog post further to mention this. I also added a mention of the "library recommendation", of which I was not aware previously.


On Tuesday, July 22, 2014 11:53:24 AM UTC-4, George Makrydakis wrote:
unfortunate posts like the one by Botond Ballo classified it as "accepted proposal".

My post did not classify fixed-size parameter packs as "accepted". I classified it under "further work", which also corresponds to the classification in EWG's report.

Regards,
Botond

George Makrydakis

unread,
Jul 23, 2014, 6:21:07 AM7/23/14
to std-pr...@isocpp.org, bot...@mozilla.com

On 07/23/2014 07:54 AM, botond...@gmail.com wrote:


That said - I recognize that, since this paper was not in the pre-Rapperswil mailing and many attendees did not get a chance to read it in advance, the discussion of it was less comprehensive than for other proposals, and therefore the outcome of such discussion should not be taken for granted. I amended by blog post further to mention this. I also added a mention of the "library recommendation", of which I was not aware previously.


tl;dr: you are not to blame.

I repeat that there was also a Saturday Morning early EWG meeting that in the end concluded that in a future meeting, this should be re-evaluated. From what I know, Ville is taking it under amendment due to EWG#30 which is addressed by my initial draft in its essence. I thank Ville for this because he validates my belief in the EWG authoritativeness and justifies why such a skilled person is the proper administrator of so many things.



On Tuesday, July 22, 2014 11:53:24 AM UTC-4, George Makrydakis wrote:
unfortunate posts like the one by Botond Ballo classified it as "accepted proposal".

My post did not classify fixed-size parameter packs as "accepted". I classified it under "further work", which also corresponds to the classification in EWG's report.

I retract the "accepted" for fixed size packs given the current status of your post and thank you for your revision.

However, fixed size packs proposal did not spawn renewed interest in index-based access for parameter packs, no they syntactically unambiguous therefore your report on that detail is still incorrect. The omission of index based access and unambiguous and homogeneous treatment of all kinds of parameter packs is the most glaring technical flaw in "fixed size parameter packs".

It is obvious that dealing with "fixed size parameter packs" becomes quite questionable without index-based access. My initial incomplete draft and presentation argued about this extensively, so there already was a technical argument against fixed size packs in their current form without access features which was totally ignored. It is not time yet to enter into more details about several aspects of this affair, but time for this will come. That is not "renewed interest", that is a fatal flaw.

If by "encouragement / further work" the EWG means that said author should integrate such features from a work they gave initially a "library recommendation" into his work, then they have the very real problem of having to justify why they motivated an author to take over another author's work which practically addresses EWG#30 for which they still have a "feature recommendation", given that both were N-less and not included in pre-meeting mailings, giving the original author a "library recommendation". The only reasonable way out of this is to accept that this was an abject procedural "blunder" on their behalf since I happen to respect the people involved. Everybody makes mistakes.

Words must have meaning. "Encouragement" belongs to the people who have actually presented and have on written record a solution that technically addresses certain issues already instead of baseless arguments using generalistic approaches like "template meta-programming scares people" (provable wrong by current bibliography, therefore a personal, not a technical opinion), "concepts can do some stuff" (the latter totally lacking generative features), "it would strain the compiler" (wouldn't fixed packs / EWG#30 "strain" the compiler as well?) ; then the following day, EWG#30 continues exploration as a language feature. Such conflicting deliberations make me ask myself why Dave Abrahams (a very skilled template meta-programmer) did not write himself a paper on this. But I digress.

I never said that I did not want to work with anybody, unlike others proving something like this with their stance. My work focuses on a series of things, some of which perhaps we should not do because they would be beyond the reach of average use. I kept those to myself anyway instead of having them written down in that infamous draft.

Reports such as yours, which have the good intention of reporting, can be used as evidence to damage being done to natural persons with legal capacity that derive from hasty generalizations in such informal deliberations. People, not organizations, can be held personally accountable when such unfortunate things happen. I do not believe that such is the case here, but what I believe does not count. What I can prove does.

Should things from my incomplete work be integrated to other works, I will continue to ask the authors responsible why they did so and report the incidents occurring due to EWG#30 stance. Given that EWG#30 will eventually be modified from what I have been told to show that there is an author like me that gets "encouragement / has interest" to work on this that won't be the case, it will be up to others to adjust their stance accordingly.

I am not letting this go. I am just letting the situation auto-rectify itself by pointing out certain - perhaps accidental - inconsistencies. I think it is clear by now. Unfortunately this will mean that you will have to eventually rectify your report again at some point. I know you meant well, are not to blame at all and do not wish to make an enemy out of you but...

L'enfer est plein de bonnes volontés et désirs.

Regards,

George



Jonathan Wakely

unread,
Jul 24, 2014, 4:01:59 AM7/24/14
to std-pr...@isocpp.org
Might I suggest that you will have a better chance of convincing the committee to listen to you and of getting people to collaborate on your ideas if you stop being so confrontational and complaining about how you've been treated.

Relax, stop complaining about damage and how much of a mess people have made. Noone is under any obligation to agree with you or accept all your ideas, no matter how right you believe you are.

Since you seem so fond of aphorisms, remember that you catch more flies with honey than with vinegar.

George Makrydakis

unread,
Jul 24, 2014, 1:09:12 PM7/24/14
to std-pr...@isocpp.org

On 07/24/2014 11:01 AM, Jonathan Wakely wrote:
Might I suggest that you will have a better chance of convincing the committee to listen to you and of getting people to collaborate on your ideas if you stop being so confrontational and complaining about how you've been treated.

Relax, stop complaining about damage and how much of a mess people have made. Noone is under any obligation to agree with you or accept all your ideas, no matter how right you believe you are.

Can the EWG explain why they gave my work that is very related to EWG#30 a library recommendation and motivated the essence of it to be delegated to other authors the next day, without providing a valid technical argument for doing so? What I believe does not count, what I can prove however does - and it is people, not organizations, who are responsible for their actions. I think that on their behalf, this is an honest mistake. Pointing that out does not make me confrontational, it makes me perhaps inconvenient.



Since you seem so fond of aphorisms, remember that you catch more flies with honey than with vinegar.

Au contraire mon Capitan! Flies are manure breeding insects; there are several insecticides and proper manure disposal according to Google (dear Google...) that help rid of flies more efficiently.

I am just waiting for an honest reply to a hopefully honest mistake, instead of having to be the little kid in Kejserens nye Klæder.

George



Tony V E

unread,
Jul 25, 2014, 5:55:50 PM7/25/14
to std-pr...@isocpp.org
On Thu, Jul 24, 2014 at 1:10 PM, George Makrydakis <irreq...@gmail.com> wrote:

On 07/24/2014 11:01 AM, Jonathan Wakely wrote:
Might I suggest that you will have a better chance of convincing the committee to listen to you and of getting people to collaborate on your ideas if you stop being so confrontational and complaining about how you've been treated.

Relax, stop complaining about damage and how much of a mess people have made. Noone is under any obligation to agree with you or accept all your ideas, no matter how right you believe you are.

Can the EWG explain why they gave my work that is very related to EWG#30 a library recommendation and motivated the essence of it to be delegated to other authors the next day, without providing a valid technical argument for doing so? What I believe does not count, what I can prove however does - and it is people, not organizations, who are responsible for their actions. I think that on their behalf, this is an honest mistake. Pointing that out does not make me confrontational, it makes me perhaps inconvenient.


Maybe it was a mistake.  The committee makes lots of them.  I wasn't there for all of the discussions, so I not sure what or why the mistake happened - maybe people were tired, or whatever.  Happens all the time.  Maybe things evolved over the days of the meeting such that a different opinion was given from one day to the next.

There have been bigger mistakes - some even make it into the language.

I have no doubt than when your completed paper is presented, it will get a valid technical discussion.
 
Tony

George Makrydakis

unread,
Jul 25, 2014, 6:08:06 PM7/25/14
to std-pr...@isocpp.org
I never asked for anything more. I am thrilled to have met some of the people involved and happily admit of my own flaws.

Thanks for your comment,

George

Reply all
Reply to author
Forward
0 new messages