DrDeadCrash

Problem is, programmers don't want AI. We want better tools that address the issues of complexity and abstract requirements management.

But only for them

I very much disagree with this, Null Reference Exceptions have been a huge problem in c#. Nullable reference types are a partial fix, but the question of "how do I 'return' an error from a statically typed method" is not answered there.

Thank you, I'd love to hear back from you.

Check the edit on the post, I thought I had linked to the GitHub page but I guess the image overrides that.

Link: https://github.com/Andy3432344/SafeResults

Check the edit on the post, I thought I had linked to the GitHub page but I guess the image overrides that.

Link: https://github.com/Andy3432344/SafeResults

The operator being applied to the ResultObject will always resolve to the Generic type that was specified as 'T in IResult. If the function is not successful the resolved value will be whatever value was supplied to the ResultObject constructor, the opt.None property will true and the opt.Some property will be false.

The example is simplified, but I dislike returning null in my own code. The function will always execute, left or right doesn't matter it's mapped across in the ResultObject class.

The function must return an IResult, the ResultObject analyzes the IResult checking for IFail or IOk. If it's IOk the value of type T is retrieved from the Value property of the IOk object and returned, the Some property defaults to true. If the IResult is an IFail, Some is set to false, it copies the message from the IFail object into the ResultObject, and returns the value the was supplied to its constructor.

I'm just sharing something I find useful, and I hope I can make it useful for others as well. Thanks for the questions.

Here's a real world side project example of how I handle this situation:

 public IResult<T> GetResourceValue<T>(string path)
    {
        string err = $"{typeof(T).FullName} is not available from this Resource ({nameof(FileSystemResource)})";

        switch (typeof(T))
        {
            case Type t when t == typeof(DriveInfo):
                return (IResult<T>)new Ok<DriveInfo>(BackingValue);
            case Type t when t == typeof(DirectoryInfo):
                err = $"Directory path invalid: {path}";
                var dir = new DirectoryInfo(path);

                if (dir.Exists)
                    return (IResult<T>)new Ok<DirectoryInfo>(dir);
                break;
            case Type t when t == typeof(FileInfo):
                err = $"File path invalid: {path}";
                var file = new FileInfo(path);

                if (file.Exists)
                    return (IResult<T>)new Ok<FileInfo>(file);
                break;
        }
        return new Error<T>(err);
    }

You said elsewhere that it feels like you're doing something wrong if you have to check for every type just to use a Generic. I think you're right in thinking along those lines. There should be a minimal number of types to check, and Ideally limited via a type constraint.

Here's example that includes a constraint:

    public IResult<T> GetValue<T>() where T : struct =>
        typeof(T) switch
        {
            Type t when t == typeof(int) && value <= int.MaxValue =>
             (IResult<T>)new Ok<int>((int)value),
            Type t when t == typeof(uint) && value <= uint.MaxValue && value >= uint.MinValue =>
             (IResult<T>)new Ok<uint>((uint)value),
            Type t when t == typeof(byte) && value <= byte.MaxValue && value >= byte.MinValue =>
             (IResult<T>)new Ok<byte>((byte)value),
            Type t when t == typeof(sbyte) && value <= (int)sbyte.MaxValue =>
             (IResult<T>)new Ok<sbyte>((sbyte)value),
            Type t when t == typeof(short) && value <= (int)short.MaxValue =>
             (IResult<T>)new Ok<short>((short)value),
            Type t when t == typeof(ushort) && value <= ushort.MaxValue =>
             (IResult<T>)new Ok<ushort>((ushort)value),
            Type t when t == typeof(long) && value <= long.MaxValue =>
             (IResult<T>)new Ok<long>((long)value),
            Type t when t == typeof(ulong) => (IResult<T>)new Ok<int>((int)value),
            _ => new IntegerError<T>()
        };

They even know they're being lied to, and still go along.

I use fancy zones for windows, and I have a zone that compromises one 4k screen and half of two others. That zone is for my VS window, two main code panes in the center and one off to each side.

It doesn't remember the layout of the tool windows... I'll have to look into the save/apply functionality you mentioned.

I prefer VS over vs-code, but in VS the window/tabs are bulky and slow compared to vs code which makes this all more annoying. First world problems though...

Edit: using VS 2022 on win 10

Not OP, but in agreement. I like to split out multiple vertical panes in VS, and I put the edges of the panes at the edge of the monitors. It's tedious to position them manually, and different tool windows run when debugging so I have to reposition the pane boundary's again whenever switching between run/design time. It would be nice if it detected the edge of the monitors and kept the scroll bars and break-point column on the correct sides of the split.