Language design question: How do you make integer division explicit?

If you didn't know the language, you wouldn't know the results of 5/2 or 5//2

5 div 2 has some precedent: I've never seen a language that doesn't do integer division with that operator, but it doesn't say it explicitly

5 intdiv 2 is explicit, but with 6 characters, it's pretty unwieldly

5 idiv 2 is shorter, but has another meaning in assembly (integer division for signed numbers. My numbers may or may not be signed)

@NathanMerrill intdiv is still ambiguous: does it round towards zero or minus infinity?

I personally like the Python's naming of floordiv.

the way C does it is objectively wrong

from a bug-free persepective, the proportion of people that expect it to round the way C does it is very small

anyways, in this regard, I'll be following what haskell does

They have div round towards -infinity

and then, in the future, if I want the other one (which is unlikely, as my language isn't meant for speed), I'll add quot

That makes sense then

that's all assuming I call it div. Which is honestly, my #1 choice right now.

but python is the worst example in this regard IMO: They have both / and // and what they mean depends on the language version

I mean, it'd be great if everybody used floordiv, but no chance of that happening :)

a story about Dantzig, dietary plans and linear programming

@NathanMerrill Python 2 is dead, long live Python 3!

@NathanMerrill i talked about this before with elendia and i actually came up with an idea which was to allow overloads to have different return types

you could then either require which overload is being used be made explicit via cast int(x / y) or make one of them the default

@El'endiaStarman we're at python 3.8, only 0.2 pythons more until we are at python 4

@flawr Haha, this is a great story!

@quartata this doesn't solve the problem of which one to pick by default

well for division maybe the answer is neither

like I said you can make it explicit either way with float or int

oh, hmmm

that's clever

but the more important part is it provides a systematic way to handle it for any function or operator, including user-defined

bonus, I can add fraction to it too

yeah.

I'm going to roll this around in my brain

thanks :)

Actually...I think that choosing the right default here will works as long as I don't auto-cast numbers

so, if I have a function that requires a float you can't pass in an integer

that's part of the problem here: People might expect it one way or another, but as long as they get an error when they expect the opposite thing, we're ok

ha...haaaa...haaaa......haskell

Gesundheit!

Danke