From: news@cct-net.co.uk   
      
   On 19/08/2025 16:10, Arne Vajhøj wrote:   
   > On 8/19/2025 10:09 AM, Dan Cross wrote:   
   >> In article <1081sk3$3njqo$7@dont-email.me>,   
   >> Simon Clubley   wrote:   
   >>> On 2025-08-18, Dan Cross  wrote:   
   >>>>   
   >>>> I happen to disagree with Simon's notion of what makes for   
   >>>> robust programming, but to go to such an extreme as to suggest   
   >>>> that writing code as if logical operators don't short-circuit   
   >>>> is the same as not knowing the semantics of division is   
   >>>> specious.   
   >>>   
   >>> That last one is an interesting example. I may not care about   
   >>> short circuiting, but I am _very_ _very_ aware of the combined   
   >>> unsigned integers and signed integers issues in C expressions. :-(   
   >>>   
   >>> It also affects how I look at the same issues in other languages.   
   >>>   
   >>> I've mentioned this before, but I think languages should give you   
   >>> unsigned integers by default, and you should have to ask for   
   >>> a signed integer if you really want one.   
   >>   
   >> Whether integers are signed or unsigned by default is not   
   >> terribly interesting to me, but I do believe, strongly, that   
   >> implicit type conversions as in C are a Bad Idea(TM), and I   
   >> think that history has shown that view to be more or less   
   >> correct; the only language that seems to get this approximately   
   >> right is Haskell, using typeclasses, but that's not implicit   
   >> coercion; it takes well-defined, strongly-typed functions that   
   >> do explicit conversions internally, from the prelude.   
   >>   
   >> But that's Haskell.  For most programming, if one wants to do   
   >> arithmetic on operands of differing type, then one should be   
   >> required to explicitly convert everything to a single, uniform   
   >> type and live with whatever the semantics of that type are.   
   >>   
   >> This needn't be as tedious or verbose as it sounds; with a   
   >> little bit of type inference, it can be quite succinct while   
   >> still being safe and correct.   
   >   
   > Kotlin is rather picky about mixing signed and unsigned.   
   >   
   > var v: UInt = 16u   
   >   
   > v = v / 2   
   >   
   > gives an error.   
   >   
   > v = v / 2u   
   > v = v / 2.toUInt()   
   >   
   > works.   
   >   
   > I consider that rather picky.   
   >   
   > Arne   
   >   
   Ada as nearly as bad, although that would work, It relies on the   
   programmer making an explicit conversion   
      
   --   
   Chris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)