On Tue, Aug 30, 2022 at 11:51 AM Михаил Найденов via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Mon, Aug 29, 2022 at 6:32 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>>
>> On Sat, Aug 27, 2022 at 11:21 AM Михаил Найденов via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>> Hello again,
>>> I ended up writing a small proposal on this topic as I am quite bothered with the issue.
>>> Attached is the draft
>>
>>
>> Hi Mikhail,
>> I looked at your paper. I think it needs to use the words "concept maps" somewhere in the paper: that's basically what you're proposing as a solution, but the paper doesn't show any evidence that you've dug into the previous proposals and why they failed.
>
>
> Hello,
> I am deliberately not providing, or investigating, a solution mainly because there is no simple one, much like you explained in Your previous post. What is the point discussing concept_maps when we don't have checked concepts, concept preservation, nominal conformance?

Because it represents a full understanding of the history of the problem domain.

The paper you contrast your proposal against similarly doesn't
directly propose a solution, but it *does* look at the history of
solutions within the problem domain so that it can formally analyze
their strengths and weaknesses.

> The proposal is a top-down view of what I believe is desirable by many - to have generic code that works on all/external types and does not require effectively a rewrite of the original algorithm and/or extensive planning just because it is generic.

This is one of my biggest problems with your proposal as written. You
identify a problem, but you don't really put forth an argument that it
is a problem. You declare that `s.starts_with` is less "awkward to
use" than `strings::starts_with(s)`, but you don't give any reasons
for this. You take it as an assumption that your audience thinks that
free functions are "objectively worse" than member functions.

I would find the proposal way more convincing if you talked about how
customization points are an idiom that's not discoverable in the
language (it's an idiom people have to learn), or how it is
disconnected from the concept it is conceptually a part of, or how it
can cause conflicts with other names in its namespace, or whatever.

"Objectively worse" is a loaded phrase, and your paper does nothing to
justify that characterization.

Lastly, I find this statement especially disconcerting:

> In a way, to use the correct style, one must plan ahead and commit to it, simple migration is not practically possible for most programmers.

... yes. Any solution to this problem, even the "generics" solution
that Zhihao suggested will *require* some degree of "planning ahead".
Polymorphism of any kind requires planning ahead.

Duck typing requires using a consistent interface within your
consuming code, and telling the external code what that interface
needs to look like. Concepts-based templates requires building a
concept and showing it off. Pure template code requires telling
everyone what the interface is. Prototype-based generics requires...
building a prototype.

You cannot have polymorphism without planning. Well you can, but it's
going to bite you sooner or later. Duck typing doesn't work if the
code consuming the object changes what "duck" looks like without
telling anybody. Concept-based templates doesn't work if you leave
something out of the concept. Etc.

There can be no solution where you can do nothing, plan nothing, just
"write code" yet make polymorphism magically work.

So if this is going to be an effective proposal, you need to outline
how much planning is OK and how much planning is not OK.