Since when this compiles?

Isn't it needs {} ?

auto parse_int_square(std::string_view const str)
    -> std::tuple<int, int>
{
  auto const i = parse_int(str);
  return i, i * i; // <-------
}


On Mon, Jun 8, 2020 at 1:53 PM Toby Brull via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> I was thinking about error-handling recently (see references [1] and [2]
> below). Of course, there are several proposals aimed at improving the
> error-handling mechanisms in C++ (p0709, p1028, p1029, p1144; p0323, p0798).
>
> I was particularly interested in p0709 (title: "Zero-overhead
> deterministic exceptions: Throwing values"). I would summarise this
> proposal here as making error-handling better by making exceptions better.
> My thought was that maybe one could tackle the problem of error-handling at
> a lower level first, and only bring exceptions into the picture later,
> especially given that some people don’t want to use exceptions.
>
> So, my idea was to allow functions to have multiple, alternative
> return-paths at the language level. Basically, a function declaration would
> be allowed to declare any number of alternative return-paths (each with an
> associated alternative return-type). The function implementation could then
> return along any of those return-paths at any point in its execution. The
> caller of such a function would always be required to handle all
> alternative return-paths in some way: either (a) explicitly (e.g. by
> throwing an exception or handling the error otherwise) or (b) by declaring
> the same alternative return-path (in which case the mechanism would work
> similar to stack unwinding). Failure to do either (a) or (b) results in a
> compile-time error.
>
> Here is a short snippet of what it might look like (inspired by [2]):
>
> int parse_int(std::string_view const str)
> ->[parse_error] std::string
> {
> std::stringstream ss; ss << str;
> int i; ss >> i;
> if (ss.fail()) {
> return[parse_error] "parse_positive_int: not an int";
> }
> else {
> return i;
> }
> }
>
> auto parse_int_square(std::string_view const str)
> -> std::tuple<int, int>
> ->[parse_error] std::string
> {
> auto const i = parse_int(str);
> return i, i * i;
> }
>
> int main() {
> std::string input;
> std::cin >> input;
>
> auto const [i, i_sq] = parse_int_square(input)
> ->[parse_error] auto const& msg {
> std::cerr << “Error: “ << msg;
> return 1;
> };
>
> assert(i * i == i_sq);
> std::cout << "i_sq = " << i_sq << '\n';
> return 0;
> }
>
> More extensive brain storming here:
> https://github.com/TobyBrull/scratchpad/blob/master/alternative_return_paths.cpp
>
> I imagine all this would still be compatible with p1028/std::error. It
> might also have other applications besides error-handling; essentially,
> every function that returns a std::variant could use this mechanism.
>
> I don't have any experience working on compilers, but I imagine this
> should be possible to implement efficiently, although it would require an
> ABI extension. I imagine the alternative returns-paths to be part of the
> function type and thus affect name mangling.
>
> What do you think?
>
> Cheers,
> Toby
>
> References:
> [1] http://lucteo.ro/2018/04/21/exception-exploration-2/
> [2] Phil Nash's CppCon 2019 talk,
> "The Dawn of a New Error" ( https://www.youtube.com/watch?v=ZUH8p1EQswA )
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>