Proposal : struct "inheritance"

[jmagaram]

Summary

Make it easier to create and use small domain-specific value objects through limited struct "inheritance"; this enables code-reuse and enables simplified struct names.

Motivation

We use classes for "big" objects like Person, Address, and Product but usually use generic string, int, Guid for the "small" values like EmailAddress, ProductTitle, and PersonId. But small intuitively-named domain objects have many benefits:

Validation in one place - Rather than sprinkling validation logic and throw expressions throughout the code to ensure that a string representing an email address is really a valid email address, you can put it in one place - the constructor of the class/struct representing the object. Then use that logic in the UI layer, business layer, and data access layer.

Type-safety - Even though a Product and Person might both be identified by a Guid it never makes sense to join on the two. Even though a Length and Weight are both represented by a float it doesn't make sense to compare them. It is an error to do LengthMeters + LengthInches without conversion. Small specialized domain objects make it more likely to fall into the pit of success because the compiler prevents meaningless comparisons/assignments between values in different domains.

Easier-to-understand code - We depend on parameter/tuple names to know what is going on rather than looking at the types of objects involved. This is a big problem with generic and anonymous delegates because parameter names are not allowed. If domain-specific types are used then parameter names become less necessary. For example, here is a view model that uses string, Guid, etc.

// Because a delegate like this is confusing, custom delegates must be defined
// Action<Guid, string, string, string, string> saveContactInformation;

delegate void SaveMeasurementsDelegate(Guid personId, float weightKg, float heightCm);

delegate void SaveContactInformationDelegate(Guid personId, string street, string city, string state, string email);

// When the user clicks OK the constructor delegates will be used to save info to a
// database. It is very difficult to see what actual parameters are necessary without
// navigating to the delegate definitions.
class EditPersonViewModelA
{
    public EditPersonViewModelA(
        SaveMeasurementsDelegate saveMeasurements,
        SaveContactInformationDelegate saveContactInformation)
    { }

    public (float weightKg, float heightCm) Measurements { get; set; }
}

This is the same view model but defined using custom primitives.

// Still need "height" parameter name on LengthCm
class EditPersonViewModelB
{
    public EditPersonViewModelB(
        Action<PersonId, WeightKg, LengthCm> saveMeasurements,
        Action<PersonId, Street, City, State, Email> saveContactInformation)
    { }

    public (WeightKg weight, LengthCm height) Measurements { get; set; }
}

A place to put the utility methods - Small domain objects need helper methods like Uri.CheckHostName, String.IsNullOrWhitespace, and Guid.Parse. If you have custom types then you've got a place to put methods like these.

You can use classes for these small domain objects, BUT…

• Performance hit of using the heap versus stack
• Must deal with null

Structs are the right technology for small values. BUT…

• Without "inheritance" if you want to re-use certain code the ratio of boilerplate to interesting code gets very high
• You can specialize structs using generics to get some code-sharing, but then the struct names become completely unwieldy to the point of being unusable. ValidatedString<string,Email> versus Email. Measurement<float, Length, MathFloat, ConvertLengthFloat> instead of just Length. Type-name aliases can help when defined within a single file but don’t work across a project or assemblies.

Example - EmailAddress (validated strings in general)

Here is some code that introduces an EmailAddress struct by wrapping a string. The EmailAddress struct has 43 lines of code but only 1 line is email-specific. By changing this single line you could repurpose the struct to validate all different types of strings - zip code, city, product name, etc. Without some kind of code sharing / inheritance it isn't easy to do that.

public interface IValidator<TValue, TError>
{
    /// <summary>
    /// Determines whether a value is valid and returns errors, if any. Custom error types makes
    /// it possible to display helpful messages in a UI layer.
    /// </summary>
    IEnumerable<TError> ValidationErrors(TValue value);

    /// <summary>
    /// Defines the value used when a struct is initialized with the default constructor. This
    /// does not have to be a valid value.
    /// </summary>
    TValue Default { get; }
}

public struct EmailAddressValidator : IValidator<string, string>
{
    static Regex _pattern = new Regex(@"^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$", RegexOptions.Compiled);

    public string Default => "somebody@domain.com";

    public IEnumerable<string> ValidationErrors(string value)
    {
        if (value == null) yield return "Can't be null";
        else if (string.IsNullOrWhiteSpace(value)) yield return "Can't be empty.";
        else if (!_pattern.IsMatch(value)) yield return "Doesn't look like an email address.";
    }
}

public struct EmailAddress : IEquatable<EmailAddress>, IEnumerable<char>, IComparable<EmailAddress>
{
    static EmailAddressValidator _validator = default(EmailAddressValidator); // The ONLY email-specific code
    string _value;

    public EmailAddress(string value) : this(value: value, validate: true) { }

    private EmailAddress(string value, bool validate)
    {
        if (validate && (!IsValid(value))) throw new ArgumentOutOfRangeException(nameof(value));
        _value = (value == NullValue) ? null : value;
    }

    public string Value => _value ?? NullValue;

    public override string ToString() => Value?.ToString();

    public override int GetHashCode() => Value?.GetHashCode() ?? -1;
    public bool Equals(EmailAddress other) => this.Value == other.Value;

    public static string NullValue = _validator.Default;

    public static implicit operator string(EmailAddress e) => e.Value;

    public static explicit operator EmailAddress(string s) => new EmailAddress(s);

    public static IEnumerable<string> ValidationErrors(string value) => _validator.ValidationErrors(value);

    public static bool IsValid(string value) => !ValidationErrors(value).Any();

    public static (EmailAddress result, IEnumerable<string> errors, bool isValid) TryParse(string input)
    {
        var errors = ValidationErrors(input);
        var isValid = !errors.Any();
        var result = isValid ? new EmailAddress(value: input, validate: false) : new EmailAddress();
        return (result, errors, isValid);
    }

    public IEnumerator<char> GetEnumerator() => ((IEnumerable<char>)Value).GetEnumerator();

    IEnumerator IEnumerable.GetEnumerator() => ((IEnumerable<char>)Value).GetEnumerator();

    public int CompareTo(EmailAddress other) => Value.CompareTo(other.Value);
}

/// <summary>
/// Here is part of a generic struct that could be used to validate all different kinds of
/// strings. Because inheritance is not supported, the validator is injected via a type argument
/// (seems like a hack). There are some problems: (1) Everywhere the type is used it has an
/// unwieldy name rather than something intuitive like 'EmailAddress'. (2) It is not possible to
/// attach type-specific instance methods, other than extension methods. (3) It is not possible
/// to attach type-specific static methods.
/// </summary>
public struct ValidatedString<TValidator, TError> where TValidator : struct, IValidator<string, TError>
{
    static TValidator _validator = default(TValidator);
    // Rest of the code not shown
}

Example : Units-of-measure

I quickly threw together some code to do units-of-measure-aware math. This is an example of how quickly the number of type parameters can get out of control. If you had an API that expected a float-based Length it would be inappropriate and cumbersome to define a method parameter type as Measurement<float, Length, MathFloat, ConvertLengthFloat>.

[TestMethod]
public void CanAddUnitsRequiringConversion()
{
    var x = new Measurement<float, Length, MathFloat, ConvertLengthFloat>(1f, Length.Feet);
    var y = new Measurement<float, Length, MathFloat, ConvertLengthFloat>(2f, Length.Inches);
    var total = (x + y).ConvertTo(Length.Inches);
    Assert.AreEqual(14f, total.Value);
    Assert.AreEqual(Length.Inches, total.Units);
}

Detailed design

I don't know much about IL, Roslyn, CLR, and the technical differences between structs and classes so bear with me. The overall goal is to make it easier to build and use small domain-specific value objects. This can be achieved by (1) sharing code between structs to limit boilerplate, and (2) enabling user-friendly struct names. One way to do this is to allow structs to "inherit" from other structs, like this.

public abstract struct Validated<T> where T : struct
{
    T? _value;

    public Validated(T value)
    {
        if (!IsValid(value)) throw new ArgumentOutOfRangeException();
        _value = (value.Equals(DefaultValue)) ? new T?() : value;
    }

    public T Value => _value ?? DefaultValue;
    protected abstract bool IsValid(T value);
    protected abstract T DefaultValue { get; }

     // Boilerplate for Equals, GetHashCode, conversions, ToString, etc. omitted
}

public struct SurveyRating : Validated<int>
{
    public SurveyRating(int value) : base(value) { }
    public const int MinimumInclusive = 1;
    public const int MaximumInclusive = 9;
    protected override int DefaultValue => MinimumInclusive;
    protected override bool IsValid(int value) => value >= MinimumInclusive && value <= MaximumInclusive;
}

The syntax is nearly the same as for class inheritance so there isn't too much to say. I suspect that prohibiting virtual methods would make it easier to implement. Abstract methods would enable code-reuse and specialization, especially since it isn't possible to customize behavior with constructor parameters - no default constructor. Because there are no virtual methods it should be possible to know exactly what member is being called at compile-time. Under-the-covers, using reflection, the derived struct may not necessarily look like it inherits from anything. SurveyRating would compile to something nearly identical to what you'd get if you copy-pasted the base-struct code into it and prefixed every member with its fully-qualified path name. Maybe there would need to be other limitations; just like today a generic constraint like where T : struct, SurveyRating or where T : struct, Validated<U> would not compile; constraints must be classes or interfaces.

Drawbacks

When using code that expects the built-in string, int, DateTime primitives, like Entity Framework, various LINQ providers, and serialization libraries, you'd have to do conversions to/from your specialized domain to the general-purpose types they expect.

Lots of code is needed to wrap primitive types to avoid losing useful functionality of those types. For example, when wrapping numeric types you need to write a lot of code to regain the math operators.

Alternatives and partial solutions

Aliases on structs and string

Type name aliases mentioned in #410 like public alias Length = Measurement<float, Length, MathFloat, ConvertLengthFloat> solves the problem of unwieldy names, and lets you use those friendly names across file/project/assembly boundaries. But it has some drawbacks: (1) Without abstract methods, you can only reuse struct code with generics - relying on a default(T) to access its static methods. This was a new technique to me and at first it seemed a bit like a hack, but I'm getting more comfortable with it. It causes type names to keep expanding (more and more type parameters) It seems less OOP, less intuitive, and more heavy-weight than overriding an abstract method like bool IsValid(string s). (2) Type-name aliases don't allow you to introduce type-specific instance or static methods, or use type-specific naming.

If ALL you had was a type name alias like public alias EmailAddress = string that crossed file/assembly boundaries and provided NO restrictions on how to create one other than an explicit cast then that would still be pretty useful. Users of the code might go hunting for the official "CreateAndValidateEmailAddress" method rather than just doing an explicit cast on a string. Not totally type-safe but pretty good.

If we had a type aliasing feature I'd want IMPLICIT conversion from a complex named thing to its alias. A method that accepts a LengthFloat should implicitly accept a Measurement<float, Length, MathFloat, ConvertLengthFloat>. But a method that accepts an EmailAddress should only allow a string that has been EXPLICITLY converted. This kind of syntax could work:

public alias Length = implicit Measurement<float, Length, MathFloat, ConvertLengthFloat>
public alias EmailAddress = explicit string

The alias feature could be beefed up to include some built-in validation:

public alias StarRating = int where value>=1 && value<=5 with default 5;
public alias EmailAddress = string where value matches regex…

This alias feature could be beefed up even more to provide a natural place for type-specific instance and static methods.

public alias Email restricts string {
    public explicit Email(string input) { // casting constructor
    {
        if (!IsValid(input)) throw new ArgumentOutOfRangeException();
        value = input; 
    }

    public Email Normalize() => new Email(value.Trim().ToLower());

    public static Email(string user, string domain) => new Email($"{user}.{domain}");

    public static bool IsValid(string input)
    {
        Regex r = new Regex("pattern");
        return r.IsMatch(input);
    }
}

Code generation

T4 code templates. I've tried this. It works eventually but is cumbersome due to lack of VS IDE support. You've got to learn a new language (the template language). Maybe some other form of code-generation is in the plan that could work.

Classes instead of structs

Use classes instead of structs. Must be careful dealing with null. Maybe for a lot of apps the performance hit of heap vs. stack doesn't matter. Our computers are insanely fast so I'd be surprised if it would negatively affect typical desktop apps. This is probably more important for things like web services.

Related issues

Internal aliases #259
Type aliases abbreviations #410
Constrained types #413
Better support for delegates, including naming parameters #470

[HaloFour]

Sounds like most of the use cases here would be covered by traits/"default interface methods". You couldn't store the state of the field in this abstract struct, but you could potentially expose a protected accessor property to retrieve it's value.

To actually implement what you've described above would seem to involve a lot of CLR changes. Is Validated<T> actually a type? Can a method accept a parameter of that type? If so, how can that method invoke any of these abstract members if not by virtual calls? If Validated<T> isn't its own type but some kind of template how do you reference them from other assemblies?

The SurveyRating use case is pretty dubious because as a struct you cannot avoid the zero-init default value which is instantly invalid. You might not have to worry about null, but you always have to worry about zero.

[whoisj]

Personally, I'd rather see the "Default Interface" solution substitute any kind of inheritance. Especially for structs.

[CyrusNajmabadi]

Tagging @gafter @MadsTorgersen . This relates to recent discussions we've had about structs and how Default-Interface-Members play along with them.

I think the desire to be able to have traits for structs will be very real. I'm hoping that if we take an approach that doesn't support struct-traits initially, we won't end up boxing (har har) ourselves into a corner such that we can't add it in the future.

[jmagaram]

It seems like a the default-interface-implementation feature resembles an abstract class, with some functionality built-in but NO instance fields. So maybe you'd have something like this interface. The boilerplate around GetHashCode, ToString, and some other stuff would be handled and would not need to be re-implemented each time.

public interface IValidatedString : IEnumerable<char>
{
    public abstract string Value { get; }
    public override int GetHashCode() => Value?.GetHashCode() ?? -1;
    public override string ToString() => Value?.ToString();
    public static implicit operator string(IValidatedString s) => s.Value; // Allowed?
    public IEnumerator<char> GetEnumerator() => Value.GetEnumerator();
}

But many of the features in my EmailAddress struct require creating a new instance of that specific struct, or comparing one EmailAddress to another. I don't want to compare any IValidatedString to another IValidatedString since they might be in different domains (Email vs. CountryCode). Would a "recursive" constraint like this work?

public interface IValidatedString<T> : IEquatable<T> where T : IValidatedString<T>, new()
{
    public static abstract IEnumerable<string> ValidationErrors(string value);

    public static bool IsValid(string input) => !ValidationErrors(input).Any();

    public abstract string Value { get; }

    private abstract void SetValueWithoutValidating(string input);

    // Probably can't implement the real constructor here
    public static abstract T New(string input)
    {
        if (!IsValid(input))
            throw new ArgumentOutOfRangeException();
        T result = new T();
        result.SetValueWithoutValidating(input); // Must be mutable; ugh!
        return result;
    }

    // Try to create via explicit cast from string
    public static explicit operator T(string input) => New(input);

    // Useful utility method to try to construct an object by parsing a string
    public static (T result, IEnumerable<string> errors, bool isValid) TryParse(string input)
    {
        var errors = ValidationErrors(input);
        var isValid = !errors.Any();
        T result = new T();
        if (isValid)
        {
            result.SetValueWithoutValidating(input);
            return (result, errors, isValid);
        }
    }

    // Compare ONLY to others of the same domain      
    public bool Equals(T other) => this.Value == other.Value;
    public override bool Equals(object obj) => (obj is T other) && this.Equals(other);
}

public struct EmailAddress : IValidatedString<EmailAddress>
{
    private string _value;

    public EmailAddress(string input)
    {
        if (!IsValid(input)) throw new ArgumentOutOfRangeException();
        _value = input;
    }

    public static abstract IEnumerable<string> ValidationErrors(string value)
    {
        // Custom validation logic here
    }

    public abstract string Value { get; } => _value;

    private abstract void SetValueWithoutValidating(string input) => _value = input;
}

Regarding the "zero" case for SurveyRating, I'd work around that like I did in the EmailAddress case. public int Value => _isInitialized ? _value : DefaultValue; I think this is common pattern for how to deal with the inability to author default constructors for structs.

As for whether Validated is actually a "type" I don't know. Assuming...

abstract struct Food { }
struct Fruit : Food { }
struct Banana : Fruit { }

Food food; // Won't compile
Fruit fruit = new Fruit(); // Ok
fruit = new Banana(); // Won't compile
List<Fruit> fruits = new List<Fruit>(); // Ok
fruits.Add(new Banana()); // Won't compile

Maybe I'm describing something more like a "template". If you couldn't subclass Food from another assembly then the feature would lose a lot of value. Like I said before, this "inheritance" approach is really just shorthand for sharing code between one struct and another.

There are many times I attempt to move in the "functional" coding direction by using immutability and value semantics for non-null and equality. I also like the DDD approach of having objects in my code that model the real-world problem domain. For smaller objects this leads me toward structs. Unfortunately structs lack the flexibility of classes - no default constructor and no inheritance - so they end up being a pain to use.

[DavidArno]

Structs were never designed to be used with inheritance, even to the extent that it's generally a good idea to avoid having structs implement interfaces as any interaction with that interfaces necessitates boxing the value.

As it mentions in the C# Language Design Notes for Apr 19, 2017, it would be incredibly hard to use trait interfaces with structs in any meaningful way without breaking changes or performance issues.

If you want a type that supports inheritance, use a class. If you want multiple inheritance, use trait-interfaces with those classes when that feature becomes available. If you want a struct, use composition, which is already available. Nothing else is needed.

[whoisj]

For those of us who prefer to avoid the HEAP when possible, Default Interfaces are the first step towards that kind of thing. We'll also need a borrow operator, struct destructors, and ideally empty struct constructors.

[DavidArno]

For those of us who prefer to avoid the HEAP when possible, Default Interfaces are the first step towards that kind of thing...

Really? Surely using structs and ref local/returns should be that first step? Or maybe the first (and last) step should be to just stick with C and manage all your own memory... 🤷‍♂️

[jmagaram]

@DavidArno , do you agree with the goal of being able to easily create small value-based objects like EmailAddress, PersonId, ProductName and numeric structs with clearly-defined units? If yes, what solution do you recommend? Classes aren't value-types and tax the heap. The best struct composition method I know about is to use generics but then you end up with unwieldy type names like Measurement<float,Length,FloatMath,LengthConversions>. Generic improvements like #395 will help get rid of some of the type arguments but you'll never end up with simple names like EmailAddress or Length. T4 works but is a hassle.

[DavidArno]

Classes aren't value-types and tax the heap

It seems to have become trendy to bitch about the heap recently. Yet managed memory using a heap and garbage collection has served millions of developers well for years. Sure, if you are writing a game for a mobile device, you may need to sacrifice every last gram of code simplicity to maximise performance. But for the vast majority of folk, the worst thing about classes has always been, and will always be null and heap/garbage collection performance is not something they never have to worry about.

do you agree with the goal of being able to easily create small value-based objects like EmailAddress, PersonId, ProductName and numeric structs with clearly-defined units? If yes, what solution do you recommend?

Type abbreviations get my vote.

[CyrusNajmabadi]

It seems to have become trendy to bitch about the heap recently.

Because it's a widespread problem that we hear about across the board. This includes internal customers and large amounts of external customers (including non-game developers). This feedback has been nonstop over the years and has only grown larger as time has gone on.

There are very real reasons that things like Nullable and tuples are value types, and it's precisely because we want these features to be wildly usable, and being expensive types works directly against those goals for so many customers.

[DavidArno]

Because it's a widespread problem that we hear about across the board. This includes internal customers and large amounts of external customers (including non-game developers). This feedback has been nonstop over the years and has only grown larger as time has gone on.

And just how much of that is genuine problems of using the heap and how much misinformation and urban myth, such as a common one that StringBuilder should be used as it avoids triggering garbage collection? Whilst clearly not universally true, in my experience GC issues are normally an indication of a bad design and a poor understanding of memory management that is better solved using memory profiling tools and some restructuring, rather than moving to ref/nullable structs.

Endlessly giving these folk more and more esoteric struct features just treats the symptoms and doesn't address underlying bad designs.

[jmagaram]

Uncle! I'll stick with classes until proven performance problems (or null) gets in the way.

[CyrusNajmabadi]

And just how much of that is genuine problems

They're very genuine problems. We work closely with partners and we've seen what's going on with them. We also see this issue directly in all our own first party efforts which have business critical scalability needs.

Consider the core code that goes into ASP.net. This is not game code. But it absolutely needs to be efficient as every piece of ASP business logic out there runs on top of it.

Remember that C# is the primary language that is used to build the platforms and libraries that so many domains sit on top of. You're right that many devs are served by the heap. But what that fails to recognize is that so much critical work is not served by the heap, and those devs you mention depend on those critical pieces :)

[Thaina]

default interface or anything related could not cover field inheritance. Block of memory with direct access is somehow convenient

Instead of the need to write some more code just to do the inheritance imitation. It far more easy to just inherit the struct

And also it make us could manage construction,readonly,namecollision and so on

[DavidArno]

Consider the core code that goes into ASP.net. This is not game code. But it absolutely needs to be efficient as every piece of ASP business logic out there runs on top of it.

Remember that C# is the primary language that is used to build the platforms and libraries that so many domains sit on top of. You're right that many devs are served by the heap. But what that fails to recognize is that so much critical work is not served by the heap, and those devs you mention depend on those critical pieces :)

So if the heap doesn't work well for frameworks like ASP.Net, then obviously those folk will now be making heavy use of structs and ref returns, right? Yet a search of that code base shows zero ref returns. That suggests that writing highly efficient code using the heap is working just great for them.

But there again why not just add full inheritance to structs, eh? It's what the folk want, so it must be good, no? 🤷‍♂️

[CyrusNajmabadi]

Do you know if that "extensions always" feature proposal is being incorporated into "Roles/Extensions" feature, or is gaining traction? It seems like a really good idea.

@najak3d let's talk offline about that.

[najak3d]

@CyrusNajmabadi wrote: "Finally, it's not my job to be aware of what you do or don't know."

Are you seriously implying that you were aware of the ability to pull in extensions via class name? At the same point as you were telling me "that this is not necessary; we're not going to augment how extensions are included just for you".

It's blatant that you also were unaware of this, at least at the time you were arguing against me. I'm not saying "it wasn't in your memory bank at all; just that you had at minimum temporarily forgotten about it".

[TahirAhmadov]

To summarize, struct inheritance using different types cannot work - ever; struct "inheritance" the way @najak3d wants is basically roles - that's #5497. The only remaining topic is my "augmentation" idea - can somebody champion that one? Please thanks :)

[CyrusNajmabadi]

Are you seriously implying that you were aware of the ability to pull in extensions via class name?

Yes. You initially indicated you wanted an approach whereby only the new type was defined, and that consumers need not do anything to pick that up. Any and all associations with extensions were rejected by you as being entirely inferior. It was only later on that it appeared that you pivoted to potentially being ok with using if it only brought in the extensions from a single file. When it was pointed out that such a concept doesn't even make sense in C#, you pivoted one final time to stating that you woudl then be ok bringing in extensions from a particular class.

I cannot guess as to what you do or don't know. Nor can i wrap my head around the set of things you do or do not find acceptable. My experience so far has been that you have an internal list of things (for lack of a better word) that you just don't like and find distasteful (regardless of how the rest of the ecosystem may perceive them). THis list has not been coherent to me, and it constantly gets strange things added and shifts around as i learn about more things you don't like using.

Until now, i had no idea that you ahd an issue with usings. And my only internalization was that it was uniformly bad, and that you would reject any solution down that path for the same reason you rejected the using Namespace approach.

Again, i'm not a mind reader here. I'm having ot adjust to the changing arugment and requirements you're coming up with as you're telling us about them.

At the same point as you were telling me "that this is not necessary; we're not going to augment how extensions are included just for you".

I said we were not going to take an entirely alternative way to effectively extend types just because you didn't like that bringing in extensions through a using-statement can pull in tons of things. That remains true. Roles/Shapes will most likely follow the way we bring in extensions today. And if we feel like we need better ways to bring in extensions, we'll just do that, instead of investing some entirely different parallel stack for accomplishing the same. Community members have raised good ideas on how to do these things, and i think an approach of Extensions/Rolse + Those ideas is much better than building something wholely new and different for the narrow case of adding some members only to structs.

To your direct point, i was the person that literally linked you to the proposal that i felt exactly matched what you were asking for. Namely a no-edit way to pull in extensions for a type. The existing capabilities and whatnot did not seem to eb what you were asking for since you still didn't want any usings at all (and i presumed that that counted global-usings which would be even more problematic since they would apply to everything in your compilation).

[CyrusNajmabadi]

The only remaining topic is my "augmentation" idea - can somebody champion that one? Please thanks :)

I'd recommend actually trying to start a discussion with that narrow scope, explaining what it is you want and what you don't. I'll tell you that if it's in line with the fork of hte convo you and i were having above, then i'm highly likely to champion it as i think it would be quite nice to have.

[TahirAhmadov]

The only remaining topic is my "augmentation" idea - can somebody champion that one? Please thanks :)

I'd recommend actually trying to start a discussion with that narrow scope, explaining what it is you want and what you don't. I'll tell you that if it's in line with the fork of hte convo you and i were having above, then i'm highly likely to champion it as i think it would be quite nice to have.

You say jump, I ask how high.

[najak3d]

@CyrusNajmabadi - I specifically said that extensions wouldn't be so bad if you could pull them in by class name instead of namespace, and you said "we're not going to change this for you; it's fine as is". This blatantly implies that what I was hoping for was "not a thing yet" -- but it was. If you had instead said "we're in luck, it already does work that way" -- it would have changed the conversation sooner. Luckily @HaloFour was reading, and informed us that it does already work (as I believe you should have recognized yourself, being that you are an expert). We all make mistakes, but it appears to me that you simply aren't willing to admit that you made this mistake. Not sure why...

So when "Roles/Extensions" adds support for extending "static members" on a struct -- that should suffice, especially now that I know this can be done in a fine-grained fashion -- class by class, instead of an entire namespace of extensions.

And you are right - I don't like a lot of "usings" -- apparently I'm not soo alone, given that for C# 10, they've made this easier to do via the "global using" notation. I also don't like abundant usings -- which clutter the intellisense with lots of stuff.

I often tend towards this notations:
using SD = System.Drawing;

rather than:
using System.Drawing;

If I'm only using 1-2 items from a namespace, I prefer the alias approach, because this way when code is cut/paste to another file, it doesn't mix-up "which Point" you wanted (there are several, all called "Point"). So "SD.Point" can never be misconstrued, and so that's what I tend to do, more times than not.

[najak3d]

I meander on what I want, because part of "knowing what I want" requires "knowing what is already available" as well as "what is difficult to achieve" and "what things open a can or worms of risks", etc.. I'm learning quickly as I go here.

Thus I meander, as I should. I'm not firm on what I want, because of new information that comes along.

And my focus isn't "what I want", but rather when I see things that I think "many would want" because these are related to issues I've seen for years.

[Xyncgas]

In C, we can use two different struct :

struct A
{
        long Id;
        long port;
}
struct B
{
        long Id;
        long port;
        int Secret;
}

And it's gonna work the same

B Obj = new B ();
MethodUsingA(&Obj );

Maybe we can have inheritance as long we are clear that struct that inheirts struct essentially put that struct on top of the struct in explicit layout

[theunrepentantgeek]

How do you handle issues of decapitation, especially when the value gets boxed onto the heap?

IIRC, C handles it by ignoring the issue, opening fertile ground for errors, memory leaks, out of bounds memory access, and other goodies of similar ilk.

[HaloFour]

@theunrepentantgeek

IIRC, C handles it by ignoring the issue, opening fertile ground for errors, memory leaks, out of bounds memory access, and other goodies of similar ilk.

This is precisely why C# forbids it, and it's incredibly unlikely that the C# team would consider enabling an entire class of bug for a tiny bit of convenience here.

[Xyncgas]

@HaloFour But it's high performance computing, we put the entire thing in the box, it's evidential via sizeof () which struct you are dealing with and what you can do with you, for one you won't access places you aren't supposed to, while the default behavior of upcasting in c# with classes is legal it should also be safe when upcasting struct because you are visiting region of the struct with guarantees that it's contained (within the struct), meanwhile downcasting will be illegal as it always has been

That being said I am very comfortable with not having inheritance at all because I can already cast a struct to another struct by defining an operator that uses parts of the struct which is built via explicit layout (e.g. Layout.Point2D)

[TahirAhmadov]

How do you handle issues of decapitation, especially when the value gets boxed onto the heap?

IIRC, C handles it by ignoring the issue, opening fertile ground for errors, memory leaks, out of bounds memory access, and other goodies of similar ilk.

Please see my proposal here: #5897
Yes, in short, you can't "cast" structs - there is no way to accomplish it in .NET and will never be possible. However, I think we can have the next best thing - special type of "inheritance" for structs which solves code reuse and helps in most other use cases. Boxing the child and unboxing into a base is theoretically possible, but would require an expensive run-time change (not likely to happen), or modifying what the C# cast operator does (not likely to happen), or using a special helper method which would accomplish it (this is relatively easy).

[Xyncgas]

It's possible, people worried about pointers accessing memory regions they are not supposed to because we changed the type of pointer in a way when we allowed struct inheritance while dealing with the so called 'diamond structure' problem by allowing overlaps of region. But what if it's not over lapped it's additive, what if the efforts is put to renaming the variables by the compiler so that you get distinguishable intellisense results in your editor or at least for example let's all agree that MyIneritedStructInstance.StructA.MyVariableA is how we use struct inheritance by basically putting them together in a bigger struct so finally the struct that inherited StructC that inherited StructB that inherited StructA... is the superset of these structs

[CodingMadness]

A super interessting and important topic more than ever, does the .NET team consider this (even slightly) or was it shrugged off entirely by now?

[timcassell]

more than ever

Why do you say that?

It looks like this just hasn't garnered enough interest to put it above other things.

[CyrusNajmabadi]

does the .NET team consider this (even slightly)

Of course.

or was it shrugged off entirely by now?

No. If that happens, we mark the discussion as such.

[CodingMadness]

does the .NET team consider this (even slightly)

Of course.

or was it shrugged off entirely by now?

No. If that happens, we mark the discussion as such.

Awesome!

Atleast like "easy-chain" value-inheritance could be a thing, like 1 simple (maybe it should not exceed like 32-64 byte in byte-size?) and then like with that only simple stuff like :

	public struct OneChainBase 
	{
	        //fields
	        public int M1, M2 = ....;
            public readonly string WhatEver = ....;

			//some property logic
            protected virtual DateTime Bla {get;}   //gets the date from any sort of different language format
    }
    
    public struct Inheriter1 : OneChainBase
    {
     	    public override DateTime Bla => DateTime.Today; //the only one you need to specify, as you know with classes already
    }

    public struct Inheriter2 : Inheriter1   //this should not be allowed to compile due to limitation of chaining
    {
     	    public override DateTime Bla => DateTime.Today; //the only one you need to specify, as you know with classes already

		    public  readonly byte[] QuiteAlotOfBytes = Get1MBData();
    }
 
    

and stuff like that