Idea for a proposal

[Nicole Mazzuca]

`Concept` in return type position:

I was talking with some people on the cpplang slack about Bjarne's
latest paper on concepts in function parameter context, and I thought
of something I would find very useful. Basically:

```
Concept foo();
```

should be equivalent to

```
auto foo();
```

except that the compiler makes certain that the deduced return type
satisfies the concept Concept; this would be useful for documentation,
without committing to a specific return type, while also making
certain that the compiler actually checks all instantiations. This
would be especially useful if, eventually, C++ gets definition
checking. However, for now, it would only check each instantiation.

This is clearly incompatible with Bjarne's proposed consistent concept
types, but it works well with independent concept types, and is, I
think, a good argument for them. A real world example where they would
be useful:

```
// note: Iterable<T, U> means that U is an iterable with value_type T

template <typename T, Iterable<T> It, typename F>
auto map(It it, F f) -> Iterable<decltype(f(std::declval<T>()))> {
struct ret {
struct ret_iter {
decltype(it.begin()) begin;
F map;
// etc.
};
struct ret_iter_end {
decltype(it.end()) end;
};

It iterable;
// etc.
}

return ret(std::move(it), std::move(f));
}
```

It's unimportant that the return type of map is `map::ret`; only that
it's an iterable with value_type that's equal to the return type of
the passed functor applied to the value_type of the iterable passed
in.

- Nicole Mazzuca (ubsan)

[npma...@gmail.com]

Notes that I forgot to put down because it's 3 in the morning:

This is impossible to represent without something like this. The closest you can get is a `static_assert`, but it won't trigger on all instantiations.

"Bjarne's Latest Proposal" - P0694R0

`Iterable<T>` can become `ranges::InputRange<T>`, I believe

[npma...@gmail.com]

Another note: these semantics were hinted at in P0464R2, but never actually defined.

[Jonathan Müller]

On 12.07.2017 11:52, Nicole Mazzuca wrote:
> `Concept` in return type position:
>
> I was talking with some people on the cpplang slack about Bjarne's
> latest paper on concepts in function parameter context, and I thought
> of something I would find very useful. Basically:
>
> ```
> Concept foo();
> ```
>
> should be equivalent to
>
> ```
> auto foo();
> ```
>

Wait, that's not what this currently is?
What does it mean right now?

[Nicol Bolas]

What it means right now is:

Concept foo();

becomes

template<typename T> requires Concept<T> T foo();

With the current wording, `foo` is a template function. With the new wording, `foo` is not a template function; it's just a regular function with an automatically deduced return type.

In both cases, the definition needs to be available in the TU (outside of explicit template specializations), since the compiler needs to figure out what the return type actually will be.

[Barry Revzin]

What it means right now is:

Concept foo();

becomes

template<typename T> requires Concept<T> T foo();

I don't think that's true? The wording in N4674 is 

A constrained-type-specifier C1 within the declared return type of an abbreviated function template declaration does not designate a placeholder if its introduced constraint-expression (10.1.7.4.2) is determined to be equivalent, using the rules in 17.6.5.1 for comparing expressions, to the introduced constraint-expression for a constrained-type-specifier C2 in the parameter-declaration-clause of that function declaration. Instead, C1 is replaced by the template parameter invented for C2 (11.3.5).

Since Concept isn't used anywhere else, then it still counts as a placeholder. So:

Concept foo(Concept ); // <==> template <class T> requires Concept<T>
                       //      T foo(T );

Concept foo();         // <==> auto foo();
                       //      static_assert(Concept<decltype(foo())>);

There's also examples like:

template <typename T> concept bool C = true;
template <typename T> concept bool D = false;
C z1 = 0; // OK: z1 has type int
D z2 = 0; // error: constraints not satisfied
C cf1() { return 0.0; }; // OK: cf1 returns double
D cf2() { return 0.0; }; // error: constraints not satisfied
auto cf3() -> C; // OK: cf3’s return type will be deduced when it is defined

[Nicole Mazzuca]

Hmm, that makes the current semantics even more strange to me. It's at least, imo, not very clear. However, if those are the correct semantics, I guess this is resolved.

--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/lzIEK6_-J84/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/65ad7b18-0aa5-49a8-bd19-1887cc8b7649%40isocpp.org.