From: arne@vajhoej.dk   
      
   On 8/20/2025 11:51 AM, Dan Cross wrote:   
   > In article <1084drl$afbj$1@dont-email.me>,   
   > Simon Clubley   wrote:   
   >> On 2025-08-19, Dan Cross  wrote:   
   >>> In article <68a493ec$0$710$14726298@news.sunsite.dk>,   
   >>> Arne Vajhøj   wrote:   
   >>>>   
   >>>> 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.   
   >>   
   >> I've not used Kotlin, but I consider that to be the really good type   
   >> of picky. :-)   
   >>   
   >>> It's kind of annoying that it can't infer to use unsigned for   
   >>> the '2' in the first example.  Rust, for example, does do that   
   >>> inference which makes most arithmetic very natural.   
   >>   
   >> I actually consider that to be a good thing. The programmer is forced   
   >> to think about what they have written and to change it to make those   
   >> intentions explicit in the code. I like this.   
   >   
   > I think the point is, that in cases like this, the compiler   
   > enforces the explicit typing anyway: if the program compiles, it   
   > is well-typed.  If it does not, then it is not.  In that   
   > context, this level of explicitness adds little, if any,   
   > additional value.   
   >   
   > That the literal "2" is a different type than "2u" is   
   > interesting, however, and goes back to what you were saying   
   > earlier about default signedness.  As a mathematical object,   
   > "2" is just a positive integer, but programming languages are   
   > not _really_ a mathematical notation, so the need to be explicit   
   > here makes sense from that perspective, I guess.   
   >   
   > In Rust, I might write this sequence as:   
   >   
   > 	let mut v = 16u32;   
   > 	v = v / 2;   
   >   
   > And the type inference mechanism would deduce that 2 should be   
   > treated as a `u32`.  But I could just as easily write,   
   >   
   > 	let mut v = 16u32;   
   > 	v = v / 2u32;   
   >   
   > Which explicitly calls out that 2 as a `u32`.   
   >   
   > Is this really better, though?  This is where I'd argue that   
   > matters of idiom come into play: this is not idiomatic usage in   
   > the language, and so it is probably not better, and maybe worse.   
      
   The practical difference for specific code is likely zero.   
      
   But there is a difference in language principles and the   
   confidence the developer can have in it.   
      
   A rule that there is never any implicit conversion or   
   literal inference no matter the context is simple to   
   understand and gives confidence.   
      
   Exceptions even in cases where it does not matter adds   
   the complexity of understanding when the exceptions apply   
   and why they do not matter. Complexity that developers   
   would rather avoid.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)