FWIW, if you want C# array idiom

int count(T)(in T[] a)
{
	debug assert(a.length==cast(int)a.length);
	return cast(int)a.length;
}

long lcount(T)(in T[] a)
{
	debug assert(long(a.length)>=0);
	return long(a.length);
}

On Thursday, 6 February 2025 at 20:52:53 UTC, Walter Bright wrote:

float f = 1; // passes
float g = 0x1234_5678; // fails

I didn’t know that, but I hardly ever use floating-point types.

However, that’s not exactly VRP, but a useful check that compile-time-known values are representable in the target type. VRP means that while you normally need a cast to assign an integer to a ubyte, you can assign myInt & 0xFF to a ubyte without cast. You can assign any run-time int to a float.

What you’re pointing out is that “micro-lossy narrowing conversions” are a compile-error if they’re definitely occurring.

On Thursday, 6 February 2025 at 09:10:41 UTC, Walter Bright wrote:

Let me guess: Pascal has no value-range propagation?

Java 23 does not have unsigned types, though. There are only operations that essentially reinterpret the bits of signed integer types as unsigned integers and do operations on them. Signed and unsigned multiplication, division and modulo are completely different operations.

Ideally, it has its own type that implicitly converts to anything that can be initialized by the constant. Of course, typeof() must return something,
there are three options:

• typeof(1) is typeof(1), similar to typeof(null)
• typeof(1) is __static_integer (cf. Zig’s comptime_int)
• typeof(1) is int, which makes it indistinguishable from a runtime expression.

D chooses the latter. None of those are a bad choice; tradeoffs everywhere.

Two questions, two answers.

That’s a vague question. If p is a slice, range error if i is signed and negative. If p is a pointer, it’s *(p + i) and if i is signed and negative, so be it. typeof(p + i) is typeof(p), so there shouldn’t be a problem.

Signed. If p and q are compile-time constants, so is p - q, and if it’s nonnegative, converts to unsigned types.

While it would be annoying for sure, it does make sense to use a function for pointer subtraction when one assumes the difference to be positive: unsignedDifference(p, q) It would assert that the result is in fact positive or zero and return a size_t. The cool thing about it is that if you expect an unsigned result and happen to be wrong, you’ll find out quicker than otherwise.

As I see it, 2’s complement for both signed and unsigned arithmetic is a straightforward choice D made to keep @safe useful. If D made any of them UB, it would exclude part of basic arithmetic from @safe because @safe bans every operation that can introduce UB. It’s essentially why pointer arithmetic is banned in @safe, since ++p might push p outside an array, which is UB. D offers slices as a safe (because checked) alternative to pointers.

In my experience, when signed and unsigned are mixed, it points to a design issue.
I had this experience a couple of times working on an older C++ codebase.

Making something valid in C do something it can’t do in C is a bad idea and invites bugs, that is true. Making questionable C things errors prima facie isn’t.

AFAICT, D for the most part sticks to: If it looks like C, it behaves like C or doesn’t compile. Banning signed-to-unsigned conversions (unless VRP proves it’s okay) simply falls into the latter box.

Of course VRP is great. For the most part, it means if an implicit conversion compiles, it’s because nothing weird happens, no data can be lost, etc. Signed to unsigned conversion breaks this expectation that VRP in fact co-created.

It’s generally good. Almost no-one complains about it.

I don’t really know what that means. Integer types in C and most languages derived from it (D included) inherited have this oddity that addition and subtraction is 2’s complement, but multiplication, division, and modulo are not (cast(uint)(-10 / 3) and cast(uint)-10 / 3 are different). Mathematically speaking, integers in D are neither values modulo 2ⁿ nor a section of ℤ.

Sounds reasonable.

On Thursday, 6 February 2025 at 16:39:26 UTC, Kagamin wrote:

What would be a “proper number”? At best, signed and unsigned types represent various slices of the infinite integers.

C# uses signed integers because not all CLR languages support unsigned types. There’s a CLSCompliantAttribute that warns you if you expose unsigned integers to your public API. That said, the case for 8-bit types is reversed: C#’s byte type is unsigned and sbyte is the signed, non-CLS-compliant variant.

On Friday, 14 February 2025 at 00:09:14 UTC, Quirin Schroll wrote:

The problem is they are incompatible slices that you have to mix due to abuse of unsigned integers everywhere. At best unsigned integer gives you an extra bit, but in practice it doesn't cut: when you want a bigger integer, you use a much wider integer, not one bit bigger integer.

It demonstrates that the problem is due to abuse of unsigned integers.