This reverts commit 8b10970836480a43a3bbb1276cb258c2a8b613f2.
This implementation has the following problems:
* It does not provide context to the less than function. This will be an
API break in order to fix.
* It uses recursion, causing unbounded stack memory usage - likely
depending on user input, which is extra problematic.
* Sorting linked lists is generally an inefficient operation;
encouraging it by having a standard library function for it may
lead to suboptimal software being written in Zig.
Furthermore, there is almost no benefit to providing a sort function as
a method, when a third party implementation can easily be passed a
linked list to then be sorted.
A parameter like this is not always optional, even if that is
usually implied. SPIR-V tools fail to parse a module with an
OpLoopMerge instruction where the loop control parameter is
left out.
Also remove the TODO--it was added in fd067fbe8b14c445ed764da15fff5163156126df, but the current code no longer used that workaround, so this TODO didn't seem relevant anymore.
* move std.atomic.Atomic to std.atomic.Value
* fix incorrect argument order passed to testing.expectEqual
* make the functions be a thin wrapper over the atomic builtins and
stick to the naming conventions.
* remove pointless functions loadUnchecked and storeUnchecked. Instead,
name the field `raw` instead of `value` (which is redundant with the
type name).
* simplify the tests by not passing every possible combination. Many
cases were iterating over every possible combinations but then not
even using the for loop element value!
* remove the redundant compile errors which are already implemented by
the language itself.
* remove dead x86 inline assembly. this should be implemented in the
language if at all.
This was originally supposed to be a lock-free queue, but I gave up on
that and made it be a thread-safe queue instead.
Putting the mutex directly inside the queue data structure makes it
non-composeable. Instead, the recommendation is to use a normal queue
protected by an external mutex.
This was originally supposed to be a lock-free stack, but I gave up on
that and made it be a thread-safe stack which is implemented poorly
using spin locks. Nobody should use this data structure.
The alternative is a normal stack protected by a mutex.
* remove `std.atomic.Ordering`
- it is provided by the language with `std.builtin.AtomicOrder`.
* remove `std.atomic.fence`
- it is provided by the language with `@fence`.
* remove `std.atomic.compilerFence`
- if this is desired, it should be a language feature, not a standard
library function with inline asm.
This reverts commit da94227f783ec3c92859c4713b80a668f1183f96, reversing
changes made to 8f943b3d33432a26b7e242c1181e4220ed400501.
I was against this change originally, but decided to approve it to keep
an open mind. After a year of trying it in practice, I firmly believe
that the previous way of doing it was better.
These arrays don't really all have an upper bound of 16; in fact they
have different upper bounds. Presumably the reason 16 was used for all
of them was to avoid code bloat with BoundedArray. Well, now even more
code bloat has been eliminated because now it's using
`ArrayList([]const u8)` which is certainly instantiated elsewhere.
Furthermore, the different corrected upper bounds can be specified at
each instance of the array list.
I consider this change to be neutral. It inlines a bit of logic that
previously was abstracted, however, it also eliminates an instance of
`catch unreachable` as well as a clumsy failed pop / append in favor of
writing directly to the appropriate array element.
This simplifies the logic. For example, in generateExactWidthType, it no
longer has to save a previous length and then use defer to reset the
length after mutating it.
In this case it improved maintainability because magic number `4` is no
longer repeated 3 times, and there is no longer a redundant branch in
the loop.
* Take advantage of multi-object for loops.
* Remove use of BoundedArray since it had no meaningful impact on safety
or readability.
* Simplify some complex expressions, such as using `!` to invert a
boolean value.
We definitely want ArrayList in the standard library. Do we want
BoundedArray? Maybe, maybe not. But that makes ArrayList a more stable
dependency for std.fs.
This is useful when you want to have an array list backed by a fixed
slice of memory and no Allocator will be used.
It's an alternative to BoundedArray as you will see in the following
commit.
