Greg Kurz writes:
> On Wed, 24 Jun 2020 18:43:00 +0200
> Markus Armbruster wrote:
>
>> This merely codifies existing practice, with one exception: the rule
>> advising against returning void, where existing practice is mixed.
>>
>> When the Error API was created, we adopted the (unwritten) rule
On Wed, 24 Jun 2020 18:43:00 +0200
Markus Armbruster wrote:
> This merely codifies existing practice, with one exception: the rule
> advising against returning void, where existing practice is mixed.
>
> When the Error API was created, we adopted the (unwritten) rule to
> return void when the fu
25.06.2020 14:23, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
24.06.2020 19:43, Markus Armbruster wrote:
This merely codifies existing practice, with one exception: the rule
advising against returning void, where existing practice is mixed.
When the Error API was created, w
Vladimir Sementsov-Ogievskiy writes:
> 24.06.2020 19:43, Markus Armbruster wrote:
>> This merely codifies existing practice, with one exception: the rule
>> advising against returning void, where existing practice is mixed.
>>
>> When the Error API was created, we adopted the (unwritten) rule to
24.06.2020 19:43, Markus Armbruster wrote:
This merely codifies existing practice, with one exception: the rule
advising against returning void, where existing practice is mixed.
When the Error API was created, we adopted the (unwritten) rule to
return void when the function returns no useful va
On 6/24/20 11:43 AM, Markus Armbruster wrote:
This merely codifies existing practice, with one exception: the rule
advising against returning void, where existing practice is mixed.
When the Error API was created, we adopted the (unwritten) rule to
return void when the function returns no useful
