LDM Notes for October 16th, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-10-16.md

Agenda

• Triage
  • Breaking change warnings
  • Determine natural type of method group by looking scope-by-scope
  • u8 string interpolation
  • Lock statement pattern
  • String/Character escape sequence \e as a short-hand for \u001b
  • New operator %% for canonical Modulus operations

[iam3yal]

We think that extension methods are probably the best path forward for getting an infix-style calling pattern for these operations.

Is this being tracked somewhere as part of the new proposal for extensions or something you might consider in the future?

[CyrusNajmabadi]

Something we might consider in the future.

[333fred]

This is not something new. This is the existing extension method syntax as it exists today.

[iam3yal]

@333fred The wording here suggests that we might be getting an alternative syntax at some point or not? to me it reads like Kotlin's infix functions. 😄

[333fred]

No. The wording says that 1.ModFloor(3) is infix-like.

[iam3yal]

@333fred ahh okay, thank you for the clarification. :)

[jnm2]

That's an incredibly mean-spirited thing to say. David goes way past crossing a line of decency in my opinion.

[En3Tho]

@CyrusNajmabadi They say the sky is the limit. But if we're talking about patience in particular then it's most probably you :D

[amis92]

@DavidArno if your protein-based CPU can't handle skipping/ignoring some messages (that are relevant for full discussion context) and you need silicone-based CPU to help with that, maybe also use silicone CPU to perform transformations of your own protein-CPU outputs with some "positiveness-enhancing" filter, and even let it fully skip posting of some of those outputs.

[jnm2]

Do you genuinely think I should have kept quiet about it and left Cyrus potentially wasting his time writing things that won't be read by the intended audience?

Even when I try to be helpful, I still get attacked. 😞

@DavidArno I believe you're bringing down the level of discourse in this repo through inflammatory remarks while believing yourself to be under attack. My heart sinks when I see it. You're seeing enemies where there are none, and you're not being fair to Cyrus, me, or others, and really none of this is about C#. From what I and others can tell, it's about you.

[AndersKehlet]

I, for one, enjoy the quotes and hope this bit of drama won't affect future decisions in that regard.

[TheUnlocked]

The modulus decision is a bit disappointing. While I agree that there are any number of potential boutique operators people might want following something like this, canonical modulus has particular practical value that other potential operators in the area don't.

BTW, should this decision also be taken as a death knell for #2585?

[CyrusNajmabadi]

One man's "practical value" is another's "boutique operator" :-)

BTW, should this decision also be taken as a death knell for

No. No decision was made on that.

[sab39]

I agree with OP, I haven't felt so strongly that an LDM decision is flat wrong in a long time (possibly since the plan to release Nullable<T> without runtime support in 2005, although obviously this one is far lower stakes).

I understand that the importance of any given feature is subjective, but I can think of dozens of times I've wanted to use canonical modulus in general-purpose non-specialized algorithms and code, and I can't see any applications at all for what we have today outside of actual mathematics.

var bucketIndex = item.GetHashCode() % buckets.Count;
DayOfWeek AddDays(this DayOfWeek day, int days) => (DayOfWeek) (((int) day + days) % 7);

If not for having followed this discussion - and for having run into bugs caused by the current behavior - it would never occur to me that 0 <= a % b < b wasn't an invariant for any positive b. And I definitely am far more obsessively interested in precise details of programming language semantics than most developers!

[CyrusNajmabadi]

but I can think of dozens of times I've wanted to use canonical modulus

Right. Any decision we make to not do something will likely not be viewed positively by a particular customer that woudl have made lots of use of that feature. So we have to look more broadly, otherwise we literally would have to do all features.

[sab39]

Right. Any decision we make to not do something will likely not be viewed positively by a particular customer that woudl have made lots of use of that feature. So we have to look more broadly, otherwise we literally would have to do all features.

Honestly, I'd be mollified if I saw someone make a plausible claim that using % for anything other than wrapping a value into the range [0, n) accounted for even a significant minority of real world code, let alone a majority. I know that my experience is always going to be limited and unrepresentative, so it's entirely possible I am unaware of a widespread need for a remainder operator in a type of code I'm not familiar with, and if so then the decision becomes a lot more subjective, even if I still disagree with it.

One other point: considering the widespread confusion about the difference between the two operations, having a separate operator would have a kind of educational or documentation-like value, in that, regardless of which of the operators a programmer actually needs for their algorithm, they would have the chance to choose it intentionally rather than potentially guessing wrong about what the operator does.

[tannergooding]

I haven't felt so strongly that an LDM decision is flat wrong in a long time

The decision to not expose remainder of floored division as a language operator doesn't negate the ability for the BCL to provide library functions that support the same and that is why dotnet/runtime#93568 was correspondingly opened.

This is, by far, not unique to C#/.NET and is something that almost every language deals with in some capacity and that has opted to deal with it in a similar manner to how LDM decided here. That is, languages do not agree on whether division and the corresponding remainder operation should be truncating, floored, or Euclidean. There is even at least one that provide the ceiling based alternative.

Which of them is correct entirely depends on your payload. Most languages do not provide multiple variants and leave it up to the library to provide alternatives to their default. Of those that do provide both, it's normally differentiated as x rem y vs x mod y and not done via symbols (i.e. x % y and x %% y).

I can't see any applications at all for what we have today outside of actual mathematics.

Computer math is ultimately not the same as real math. Computers are operating with many more constraints and as such we have to consider scenarios like rounding and overflow as a part of every operation. We do not have access to infinite precision, unbounded range, or even the ability to trivial replace concepts with abstract symbols. Instead, we work with finite precision, finite range, finite time, finite memory/resources, etc.

Because of this, computers have caused an introduction and consideration of all kinds of new or additional rules that tweak the invariants you may otherwise be used to. You have to consider that x + 1 > x may not hold true. You have to consider that x + 1 may be significantly more expensive than y + 1. You have to consider that (a + b) + c and a + (b + c) may not be equivalent. You have to consider that every operation may introduce additional error, and so on.

Correspondingly, this also means thinking about ways you can achieve the same functionality differently or more efficiently. Hardware opted for truncated division because it is simply cheaper than any other kind of division. Remainder of truncated division then naturally falls out of that using a consistent algorithm as for other types of remainders. You can then use these "cheapest foundational" operations to resolve the other types of division or remainders for only a minor additional cost.