From: cross@spitfire.i.gajendra.net   
      
   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.   
      
   Which begs the question: who do we write our programs for?  Note   
   that I don't ask "what", but rather, "who": sure, we write code   
   to (hopefully) make the machine do something useful, but really   
   we use these notations we call "programming languages" for   
   ourselves and for each other.  So what are the characteristics   
   of that audience?  In particular, what level of proficiency   
   should I assume when I write code in a particular language?  Do   
   I write for programmers who are not familiar with the language   
   and its idioms, or the do I assume a greater level of   
   familiarity?  Personally, I err on the side of the latter, but   
   then I'm often writing code in a domain where casual changes   
   rarely work.  Still, like all things, I think there's a balance   
   here, and I am very tired of the mentality that programming   
   _should_ be hard just because it should.   
      
   	- Dan C.   
      
   Just as an aside about Rust, note that variables are immutable   
   by default; in the above example, I can avoid `mut` and write:   
      
   	let v = 16u32;   
   	let v = v / 2;   
      
   Which shadows the original binding, but gives the same effect as   
   the version that uses `mut`.  _This_ is subjective, and not a   
   matter of idiom, however.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)