The new Number primitive attempts to account for many numeric types at once and these types all have non-generic interfaces which need to be implemented:

• Implement IComparable.
• Implement IConvertable.
• Implement ISpanFormattable.
• Implement IUtf8SpanFormattable.

The Number primitive needs support for double:

• Implement IEquatable<double>.
• Implement IComparable<double>.
• Implement IBinaryFloatingPointIeee754<double>.
• Implement IBinaryFloatParseAndFormatInfo<double>.
• Implement IMinMaxValue<double>.
• Implement basic arithmetic operators (+, -, *, /, and %).
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The Number primitive needs support for byte:

• Implement IEquatable<byte>.
• Implement IComparable<byte>.
• Implement IMinMaxValue<byte>.
• Implement `IBinaryInteger.
• Implement IUnsignedInteger<byte>.
• Implement IBinaryIntegerParseAndFormatInfo<byte>.
• Implement IUtfChar<byte>.
• Implement basic arithmetic operators (+, -, *, /, and %).
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The Number primitive needs support for Int128:

• Implement IEquatable<Int128>.
• Implement IComparable<Int128>.
• Implement ISpanParsable<Int128>.
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The currently defined test methods don't clearly articulate what is actually being tested, which is critical given the indirect and sometimes rather obscure naming of the methods utilized to achieve terse code to levels that are competitive with more golf-friendly languages. Take the tests for the methods for generating ranges for example:

[Fact]
public void GR_SingleParam_Generates_Correct_Range()
{
    var count = 5;
    var result = Gr(count);
    Assert.Equal(Enumerable.Range(1, count), result);
}

For starters, this fully-underscored naming convention needlessly extends the name and adds little to no value. That can be simplified to separating the method, condition, and result; for example, the method above could be simplified to:

public void GR_SingleParam_GeneratesCorrectRange();

Additionally, the GR here isn't as useful as it could be from a maintenance perspective. Instead, let's expand the name to its more legible representation GenerateRange. While it doesn't match the actual method being tested, it helps developers maintaining the project better understand the code they're working with:

[Fact]
public void GenerateRange_SingleParameter_GeneratesCorrectRange()
{
    var count = 5;
    var result = Gr(count);
    Assert.Equal(Enumerable.Range(1, count), result);
}

This issue covers the correction of the test methods defined in:

• Generate Range Tests (tested methods)
• Filter Tests (tested methods)

The Number primitive needs support for uint:

• Implement IEquatable<uint>.
• Implement IComparable<uint>.
• Implement ISpanParsable<uint>.
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The Number primitive needs support for float:

• Implement IEquatable<float>.
• Implement IComparable<float>.
• Implement IMinMaxValue<float>.
• Implement IBinaryFloatingPointIeee754<float>.
• Implement IBinaryFloatParseAndFormatInfo<float>.
• Implement ISpanFormattable.
• Implement IUtf8SpanFormattable.
• Implement basic arithmetic operators (+, -, *, /, and %).
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The Number primitive needs support for short:

• Implement IEquatable<short>.
• Implement IComparable<short>.
• Implement IBinaryInteger<short>.
• Implement IMinMaxValue<short>.
• Implement ISignedNumber<short>.
• Implement IBinaryIntegerParseAndFormatInfo<short>.
• Implement basic arithmetic operators (+, -, *, /, and %).
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The Number primitive needs support for ulong:

• Implement IEquatable<ulong>.
• Implement IComparable<ulong>.
• Implement ISpanParsable<ulong>.
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The Number primitive needs support for ushort:

• Implement IEquatable<ushort>.
• Implement IComparable<ushort>.
• Implement IBinaryInteger<ushort>.
• Implement IMinMaxValue<ushort>.
• Implement IUnsignedNumber<ushort>.
• Implement IBinaryIntegerParseAndFormatInfo<ushort>.
• Implement basic arithmetic operators (+, -, *, /, and %).
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

🔢 Version

🐣 Pre-Release

🤔 What's happening?

The README currently presents Hussy.Net as a programming language, but it's a .NET dialect.

🎉 What was your expectation?

The README should say it's a .NET dialect, not a programming language.

🪜 Steps to Reproduce

Not applicable.

The Number primitive needs support for int:

• Implement IEquatable<int>.
• Implement IComparable<int>.
• Implement ISpanParsable<int>.
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

Let's call it F for Filter.

A primitive capable of handling the primitive types of C# would help simplify a lot of golf snippets. This type will be known simply as Number and consumable as N:

N foo = 3.14159f;

Ideally, we should have a file per interface implementation required to support the type:

    public readonly struct Number
        : IComparable,
          IConvertible,
          ISpanFormattable,
          IComparable<Number>,
          IEquatable<Number>,
          IBinaryInteger<Number>,
          IMinMaxValue<Number>,
          ISignedNumber<Number>,
          IUtf8SpanFormattable,
          IBinaryIntegerParseAndFormatInfo<Number>

Then one per native primitive being supported to handle conversions:

• byte
• short
• ushort
• int
• uint
• long
• ulong
• decimal
• float
• double

This will likely be the most verbose primitive type the project will have. As a result, the support for each native primitive is approved to be defined in its own file under a folder named Number which is marked as not a namespace provider, as is typical of all folders in the repo. The naming format should be *Functions where * represents the native type (e.g. ByteFunctions) or similar to ensure functionality can be maintained in bite-sized chunks.

The Hussy.Net.Terminal project is a great way for golfers to test their snippets, but deploying Hussy.Net as a NuGet package allows them to set up a project locally for their snippets. Ideally, the package would be friendly to that scenario and make it where consumers do not have to define the global using directives themselves.

The current expected output for this would be:

global using Hussy.Net;
global using static Hussy.Net.Hussy;

The source generator should be in it's own project Hussy.Net.Generators.

Let's call it M for Map.

A primitive for handling text information is needed and should handle both of the native primitive types:

• char
• string

This type should be called Text and will be aliased as T:

T sample = "Hello, world!;

The Number primitive needs support for long:

• Implement IEquatable<long>.
• Implement IComparable<long>.
• Implement ISpanParsable<long>.
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.

The Number primitive needs support for UInt128:

• Implement IEquatable<UInt128>.
• Implement IComparable<UInt128>.
• Implement ISpanParsable<UInt128>.
• Unit test coverage for the implementations.

Note: The unit test coverage for the IEquatable implementation will be contributed by the repo owner.