On 5/2/23 12:37 PM, Gašper Ažman wrote:
> I'd be strongly opposed to introducing a yet another syntax to
> introduce dependent names. There's nothing wrong with current
> template-heads.
>
> That said, there is a missing place for syntax that *doesn't* put the
> concept into the immediate context but merely checks it after the
> overload has been chosen, but that can appear in declarations. That'd
> be really nice to have to document the expectation but *not* use it
> for overloading because it's expensive.

Or because sometimes you don't want the compiler to issue an error
detailing all 1197 overloads that didn't match the call arguments.

Or because sometimes you don't want to leave any potential for overload
resolution to settle on a less refined overload (as can happen when, for
example, an iterator type is expected to satisfy random access
requirements but fails to for some mundane mistake made in its definition).

Tom.

>
> On Tue, May 2, 2023 at 5:33 PM Tom Honermann via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> On 5/2/23 12:13 PM, Andrew Tomazos via Std-Proposals wrote:
>> Regardless of the polls, politics or history: I think the
>> underlying design principle should be that: a type, a concept and
>> auto should be interchangeable. All three are sets of types.
>
> That is factually incorrect. A concept is not a type; a concept
> may be defined so as to constrain types, values, templates, or
> combinations thereof. The concept auto syntax does in fact name a
> constrained type (given an appropriately defined concept).
>
> Tom.
>
>> A type represents the set of types of size one that includes only
>> that type. A concept represents the set of all types that
>> conform to the concepts requirements. auto represents the set of
>> all types (aka the anything concept or the wildcard concept). All
>> three should be able to appear syntactically wherever one can
>> appear, and to mean "one of the types of this set of types". The
>> implications of that should be secondary.
>>
>> On Wed, May 3, 2023 at 1:42 AM Barry Revzin via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>
>>
>>
>> On Tue, May 2, 2023, 8:05 AM Ville Voutilainen via
>> Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Tue, 2 May 2023 at 14:32, Andrew Tomazos via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> > They added this auto nonsense at the last minute
>>
>> The slight problem with that claim is that it's
>> incorrect; the
>> constrained-deduced syntax wasn't added at the last minute.
>> The other problem is that while you're entitled to
>> calling whatever
>> you like nonsense, there are significant technical
>> advantages to the approach we ended up choosing (Nota
>> Bene: this "we"
>> excludes the author of the email I'm responding
>> to, as he wasn't a participant in any of it, so feel free
>> to take his
>> reports on what happened and why with a modicum
>> of suspicion, as it's not based on first-hand
>> experience), so there
>> are plausible reasons to think that it's far from nonsense.
>>
>>
>> +1
>>
>>
>> > Most think that's silly and not worth fouling up the syntax
>>
>> The slight problem with this claim is that it has no
>> evidence backing it.
>>
>>
>> +1.
>>
>> For instance, in Jacksonville there was a poll for the
>> Concepts TS syntax with independent binding - that is: void
>> f(Concept, Concept) can take two different types. That poll
>> was 23-15-26.
>>
>> There was another poll for independent binding plus some
>> unspecified syntax indicating that the function is a
>> template. That result was 40-16-11.
>>
>> Hard to interpret that as "most think it's silly."
>>
>> Barry
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>