Date: Wed, 10 Jun 2020 10:26:16 +0100
Many thanks for your comments.
@Jake: Not sure I understood your proposal, or how exactly it would relate
to this one here. It looks like in your approach you would be able to use
the same code-fragment/function-body for multiple return-types? This
wouldn't be possible here (at least without modifications), and what I
proposed would probably be less dependent on the type-system (this could
also be changed, of course)? I also didn't understand exactly what you
meant by "data pipelines"?
@Richard: It might be logically equivalent to exceptions, although I
personally can't say that I would find it harder to read. I guess you could
think of it as akin to a form of exceptions, where a function is forced to
declare each and every type of exception that it may throw, and a caller is
forced to handle each and every type of exception that called functions
throw (i.e., a more explicit version of p0709). What strikes me as odd
about p0709, is that it would allow a local treatment of exceptions/errors,
but would keep the "throw-catch" lingo. For me, "throw-catch" seems to
imply that the "throw" and "catch" may be a couple of stack-frames appart.
Also, I find "throw-catch" to be tightly linked to the current dynamic
(table-based or stack-based) exception mechanism. So, a different syntax
(and semantics) for error handling might provide a cleaner expression of
the concept, with the ability to offer a fresh start.
Cheers!
On Mon, 8 Jun 2020 at 14:54, Richard Hodges via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
>
>>
>> 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?
>>
>>
> To me this looks logically equivalent to exceptions, but harder to read.
>
>
>
>> 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
>>
>
>
> --
> Richard Hodges
> hodges.r_at_[hidden]
> office: +442032898513
> home: +376841522
> mobile: +376380212
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
@Jake: Not sure I understood your proposal, or how exactly it would relate
to this one here. It looks like in your approach you would be able to use
the same code-fragment/function-body for multiple return-types? This
wouldn't be possible here (at least without modifications), and what I
proposed would probably be less dependent on the type-system (this could
also be changed, of course)? I also didn't understand exactly what you
meant by "data pipelines"?
@Richard: It might be logically equivalent to exceptions, although I
personally can't say that I would find it harder to read. I guess you could
think of it as akin to a form of exceptions, where a function is forced to
declare each and every type of exception that it may throw, and a caller is
forced to handle each and every type of exception that called functions
throw (i.e., a more explicit version of p0709). What strikes me as odd
about p0709, is that it would allow a local treatment of exceptions/errors,
but would keep the "throw-catch" lingo. For me, "throw-catch" seems to
imply that the "throw" and "catch" may be a couple of stack-frames appart.
Also, I find "throw-catch" to be tightly linked to the current dynamic
(table-based or stack-based) exception mechanism. So, a different syntax
(and semantics) for error handling might provide a cleaner expression of
the concept, with the ability to offer a fresh start.
Cheers!
On Mon, 8 Jun 2020 at 14:54, Richard Hodges via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
>
>>
>> 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?
>>
>>
> To me this looks logically equivalent to exceptions, but harder to read.
>
>
>
>> 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
>>
>
>
> --
> Richard Hodges
> hodges.r_at_[hidden]
> office: +442032898513
> home: +376841522
> mobile: +376380212
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-06-10 04:29:38