Typo in idioms/coercion-arguments.md  #377

Activity

1. horw

   changed the title [-]typo in idioms/coercion-arguments.md [/-] [+]Typo in idioms/coercion-arguments.md [/+] on Oct 13, 2023
2. neithernut commented on Oct 13, 2023

   

   neithernut

   on Oct 13, 2023

   Contributor

   More actions

   Disclaimer: not a maintainer

   I don't think this is a typo. Yes, vowel_count will never be greater than 3, but I, too, would have chosen >= over == in this case, because I usually go full state coverage if given some condition like in this. With a ==, states with vowel_count < 3 are taken care of because we intend to continue to iterate and the state with vowel_count is also obviously taken care of, but all states with vowel_count > 3 are not.

   Going for full state coverage is, at least in my experience, something you learn to appreciate if you do anything safety-related ¹. It makes your stuff more resilient against all kinds of things, including random bitflips (e.g. in environments with higher radiation such as space) ² and human error committed by some developer ³. This may seem paranoid, but in these cases being paranoid doesn't hurt.

   The >= doesn't even come with any extra cost. The HW instruction for comparing/conditional jump should be equally wide for == and >=, and you'll likely not being able to measure a significant difference in speed or power consumption either.

   Footnotes

   1. and/or if you have written enough C ↩

   2. Granted, if you specifically wanted to maximize change of a correct result under the assumptions of bitflips only in vowel_count, you'd do a few calculations and likely end up with == after all. But in the general case full coverage is still preferable. ↩

   3. especially in projects involving C code ↩

   👍React with 👍3Reacted by Igor Udot, simonsan and ♫ Christian Krause ♫
3. horw commented on Oct 13, 2023

   

   horw

   on Oct 13, 2023

   Author

   More actions

   Hi @neithernut, thanks for your review!
   You mentioned saved programming and its really important, but in this case what I see:

   • it's a func that calls three_vowels, so it will be strange if there will be 4..etc, if we say about save programming it will have to raise error because it's unexpected behaviour
   • let mut vowel_count = 0; it's not reference, just usual variable
4. simonsan commented on Oct 13, 2023

   

   simonsan

   on Oct 13, 2023

   Collaborator

   More actions

   • it's a func that calls three_vowels, so it will be strange if there will be 4..etc, if we say about save programming it will have to raise error because it's unexpected behaviour

   I don't agree, a word that contains 4 consecutive vowels does also contain 3 consecutive vowels. So you wouldn't ever expect a word with 4 consecutive vowels to get a false response from three_vowels, wouldn't you? I think this example is correct - for what it is, an example.

   How someone would implement that in production, depends on a variety of different factors, for sure. And this implementation might not be well suited if you want to determine differences between 3 and 4 vowel words.

   👍React with 👍1Reacted by Igor Udot
5. rust-unofficial

   locked and limited conversation to collaborators on Mar 17, 2024
6. simonsan

   converted this issue into a discussion #401 on Mar 17, 2024