On Thursday, 19 May 2022 at 18:39:51 UTC, Walter Bright wrote:

Agreed. But asserts are often used without regard for performance, because it's assumed they are removed from release code. Which puts pressure to disable them from a release build

We can do a bit better. If an assert trips, the program will go to unknown state, and there's no telling what it will do. But that's still not quite the same as undefined behaviour. If the program trips an assert in @safe code, it probably won't cause a buffer overflow vulnerability, because @safe would almost certainly have detected a vulnerability if one existed. But if the spec says "undefined behaviour", the compiler is allowed to optimise so that it creates such a vulnerability - see the linked thread for an example. I know the current compilers do not do that, but the spec allows doing so in the future.

On Thursday, 19 May 2022 at 20:17:36 UTC, Dukc wrote:

Isn't the advice to use enforce for handling/verifying input in release builds and assert for development builds though?
Yeah, it's violating DRY if a particular check needs to be done in both development and release, but then one can skip the assert and just do enforce, no?

On Thursday, 19 May 2022 at 18:42:11 UTC, Walter Bright wrote:

Some programming languages just maintain the order of insertion (Ruby, Crystal, Python, ...) for their associative arrays and this makes their behavior much more predictable and friendly to the developers.

Go intentionally randomizes the order of iteration over elements from its associative arrays, so that the unpredictable nature of it is much more visible to the developers and can be caught by unit tests.

Every little bit helps to improve safety. You skipped my comment about default unstable sort in Phobos, but such decision also erodes safety to some extent.

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

I decided not to question the whys... D simply follows it's "winding" path (like Paul McCartney's Beatles song).

I use it as an scripting language and I simply wait for some productive "things" to be incorporated one day: named parameters, strings interpolation, unlimited UFCS, null safety (or Optional/Some/None native support, or union types or whatever D decide to do), better optional typing inference (at least, as powerful as dart or typescript or ...), nice D debugger inspector (at least, as powerful as java or javascript or c# or ...).

I'm not the one to be involved in D experts brainy discussions.

Languages are tools... just use the one that fits your needs. It can be D or not.

On Friday, 20 May 2022 at 07:01:09 UTC, Siarhei Siamashka wrote:

I'm not sure how a unittest can catch it, because even if the order is randomized then it can in theory end up being ordered.

On Friday, 20 May 2022 at 09:26:58 UTC, bauss wrote:

D unittest (save as "main_test.d" and run as "rdmd -unittest main_test.d"):

unittest {
	// Create an associative array
	auto a = ["Alice": true, "Bob": true, "Charlie": true];

	// Iterate over the associative array and save keys
	string[] s;
	foreach (k, _ ; a)
		s ~= k;

	// If the order is preserved, then the first retrieved name will be "Alice"
	assert(s[0] == "Alice");
}

void main() {
}

Go unittest (save as "main_test.go" and run as "go test main_test.go"):

package main

import "testing"

func TestAssocArrayOrder(t *testing.T) {
	// Create an associative array
	a := map[string]bool{"Alice": true, "Bob": true, "Charlie": true}

	// Iterate over the associative array and save keys
	var s []string
	for k, _ := range a {
		s = append(s, k)
	}

	// If the order is preserved, then the first retrieved name will be "Alice"
	if s[0] != "Alice" {
		t.Fatalf("The first returned key was not 'Alice'! The actual order: %v", s)
	}
}

In Go this unittest will sporadically fail and the problem will be detected reasonably fast. Of course, assuming that the unit tests are run regularly.

On Friday, 20 May 2022 at 12:45:07 UTC, Siarhei Siamashka wrote:

unittest {
	// Create an associative array
	auto a = ["Alice": true, "Bob": true, "Charlie": true];

	// Iterate over the associative array and save keys
	string[] s;
	foreach (k, _ ; a)
		s ~= k;

	// If the order is preserved, then the first retrieved name will be "Alice"
	assert(s[0] == "Alice");
}

void main() {
}

The problem quickly shows when you dig slightly deeper. Import another module. It fails. Add -i, it work, but now run the unittests of the module you import. Bonus point: dependencies are not tracked properly so you might be running stale code.