Surprise T Rex posted:

Are there any good resources on how people tend to use things like Records/Record Structs, Pattern Matching, and other newer language features in the real world?

Everything I’ve seen so far is just toy examples (“Person(string name)” level stuff), but it’d be cool to see how people are using them to make things nicer.

Semi-related, what are peoples thoughts on stuff like using small private types internally in a class to essentially replace Tuples or anonymous objects? Useful or just noise?

Kyte posted:

code:

			var tasks = (
				apiMaestros.ObtenerCuentaAsync(participante.beneficiario_rut),
				apiMaestros.ObtenerEtniasAsync(),
				apiMaestros.ObtenerDiscapacidadesAsync(),
				apiMaestros.ObtenerRegionAsync(contacto.id_region),
				apiMaestros.ObtenerProvinciaAsync(contacto.id_provincia),
				apiMaestros.ObtenerComunaAsync(contacto.id_comuna)
				);

			var (cuenta, etnias, discapacidades, region, provincia, comuna) = await tasks;

NihilCredo posted:

C# code:

var thing = fetchSome(usershit);

if (thing is { SomeProperty = null }) {
   log("your poo poo is hosed");
   return;
}

DoSomething(thing.SomeProperty);

The guard clause desugars to "thing?.SomeProperty == null", so it will catch a null 'thing', which is the right choice. But having a specific property being null is a different error than the entire object being null (the former means the client hosed up, the latter could be the fetchSome function that hosed up).

No Pants posted:

I might be missing something, but that code block will throw a NullReferenceException if thing is null. A property pattern only matches an expression if the expression result is not null.

quote:

A property pattern checks that the input value is not null and recursively matches values extracted by the use of accessible properties or fields.

Red Mike posted:

Property patterns won't throw if it's null, it'll just early quit and act as if it's not a match.

From https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/patterns#property-pattern.

Potassium Problems posted:

I want to say that returning a type that inherits from ObjectResult will ensure you don't have to materialize the list & will stream it to the client, but I don't know if that's true or not and I can't seem to find any documentation on it

NihilCredo posted:

I think IActionResult simply predates ActionResult<T>. Before ASP.NET Core... 2 or 3 or something, returning IActionResult was the only option if you had a code path returning Ok(apples) and another returning NotFound("missing tree").

That said, all it really does is saving you from maintaining a [Produces(typeof(IEnumerable<Apple>)] attribute, for the benefit of OpenAPI generators and the like. Anything that's wrapped inside an ObjectResult still bypasses typechecking:

C# code:

public ActionResult<Apple> GetApple()
{
    return new Apple(); // ok
    return new Orange(); // compiler error

    return Ok(new Apple()); // ok
    return Ok(new Oranges()); // ok
} 

epswing posted:

Ok, makes sense. Is it considered bad form for different code paths to return different types?

Red Mike posted:

Personally I don't mind tuples even in production code as long as they're named, but I really dislike code that is built to use them as basically half-baked collections; that's not what tuples are. Same with anonymous types, although those are at least much more difficult to try to use like this (but not impossible as proven by code I've run into before).

You're basically building new boilerplate logic on top of code that has particular behaviours, in order to take advantage of one minor part of its behaviour (tuple deconstruction). Worse, you usually end up not even able to take full advantage of it, because for example in this code above: it's trivial for someone to change the order of two of the lines in the task definition, then not change the order of the results in the awaiting line. If the two changed lines return the same type (like say a string), you won't even notice.

What I tend to use tuples for is basically as a replacement for a struct/record while writing small bits of code that doesn't tend to move across layers of the application. I don't generally like returning tuples from public methods (and never from a library), but even returning from a public method is acceptable if the number of values is well defined and it's a one-off/rarely used request (e.g. you have a service that retrieves a bit of data, or the children of a bit of data, or both; if "both" is something that's only used in a minor place like a debug method/analytics tracker/etc, then I have no issue using a tuple instead of an actual type).

e: I also use tuples to avoid out parameters...because of all the places where out parameters don't work anyway. But again if it's a public method/library method, then I'll use a type unless it's a one-off/minor request that I don't care enough about. Usually even then I'll only use a tuple if it's a compound version of existing types.

biznatchio posted:

epswing posted:

I can’t find it but I’ll edit in the emote for the guy pointing and nodding later.

NihilCredo posted:

You don't need factory methods, you can just use named arguments to bypass the default overload resolution rules:

C# code:

var x = new ServiceResult<int, string>(id : "foo"); // will invoke the generic constructor

biznatchio posted:

And, incidentally, don't design your ServiceResult class to have both a singular Result property and an separate multi-value Results property. The methods you're calling that will be returning this object will know if they're going to be returning a single value or multiple values. Let them handle it by returning ModelResult<IList<ModelType>, long> instead of making a lot of annoying confusion for developers who will work on your codebase in the years to come as to whether they should be looking at Result or Results in every single result object they ever interact with.

quote:

Also, since I've seen this anti-pattern often enough to have an idea of what it might be used for: don't use ServiceResult objects internally between C# layers of your application. They're fine to shape Web API contract output, but a lot of developers insist on bringing over development practices from worse languages or have a massively misplaced fear of using exceptions for error reporting and end up making a huge mess of their internal codebases by building these sorts of bespoke result types rather than just returning the actual value you actually wanted from methods and using exceptions for failures.

Admiral Snackbar posted:

I have a question about including an expression in an EF select operation. If I run this code against SQL Server:

code:

var tc = ctx.TestClasses
            .Select(x => new
            {
                FullName = x.GroupName != null && x.DisplayName != null
                           ? $"{x.GroupName.Substring(0, 3).ToUpper()}: {x.DisplayName}"
                           : string.Empty
            })
            .ToList();

RC Cola posted:

I have to migrate from framework 4.6.1 to netcore 6 on a pretty complex bit of software. its uh. fun?

Also its only one day a week that I work on it lol

mystes posted:

I think regardless of the complexity of the software it entirely just depends on whether you're using specific features/dependencies that don't work in .net 6 that you have to replace; otherwise there aren't a lot of backwards incompatible changes and it should be trivial

Admiral Snackbar posted:

I appreciate everyone's feedback on this. I wanted to see if I could make this work by manipulating expression trees, and I put together a visitor that actually works (at least for anonymous types):


Now, whether or not this is actually a good idea is another question...

RC Cola posted:

there are so so so many specific features and dependencies that don't work anymore

RC Cola posted:

there are so so so many specific features and dependencies that don't work anymore

RC Cola posted:

I have to migrate from framework 4.6.1 to netcore 6 on a pretty complex bit of software. its uh. fun?

Also its only one day a week that I work on it lol

ChocolatePancake posted:

I've heard good things about NSubstitute and FakeItEasy, but haven't had a chance to test myself yet.
For what it's worth, it looks like the change got rolled back for now due to an incompatibility with MacOS.