-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discosal: Null-conditional return #437
Comments
I'd throw public static IEnumerable<T> GetValueTypeItems<T>(
IList<T> collection, params int[] indexes)
where T : struct
{
// Highly indicative of a bug; null and empty should mean two different things.
// yield break if you absolutely must.
if (collection == null) throw new ArgumentNullException(nameof(collection));
foreach (int index in indexes)
{
yield return collection[index];
}
} |
@jnm2 |
@lachbaer |
@jnm2 Yes, you're right, I just copied it from the mentioned source. Should be |
So leaving the example aside:
|
I keep reading the portmanteau in the title as a misspelling of "disposal." I'm not sure that's the sound we should be shooting for 😄 |
How about "Propussion"? 😂 Like with any It could be a logical extension to the language to suffix other expressions with On the other hand, when non-nullable reference types will come, the use cases of |
I knew you would go there... let's hope these threads don't lead to concussions 😁 |
I'm strongly in favor of I'm a little concerned that the next ask would be |
@jnm2
foreach (var item in myList)
{
return? item.CreateObjectIfConditionMet(item);
} or alike... |
This is why I was skeptical. ;-)
foreach (var item in myList)
{
if (TryCreateObjectIfConditionMet(item, out var obj)) return obj;
} |
You could write a local function (btw, the |
I had to solve a bug just a few days ago that could exactly be prevented by this construct. It took me hours to pinpoint the problem and it turned out my dear coworker did a yield return in a foreach loop before checking for null. That meant only the first item was checked and the others in the foreach loop were always ignored. Granted, with the proposed construct you could also make the mistake of not using ?, but I do feel that this is such an easy mistake to make and when you know 'yield return?' is this new cool C# feature, it could save us some hours and allows us to get on with it. |
Actually, the code problems described here could be expressed in a much more meaningful way: return indexes.Select(index => collection[index])
.Where(x => x != null)
.Cast<int>();
// or
var result = from index in indexes
let item = collection[index]
where item != null
select (int)item;
return result;
// instead of
foreach (int index in indexes)
{
T? item = collection[index];
if (item != null) yield return (T)item;
} And with if? (var res = item.CreateObjectIfConditionMet(item))
return res;
// instead of
return? item.CreateObjectIfConditionMet(item); The other forms are a bit longer than |
Wouldn't it be enough for The consequences of |
Me too. The approach I take is to avoid having |
Wise saying, but that is in praxi mostly not the case. Also when being "in a flow" most people probably don't "stop", but keep on writing. After a while there already is working code, maybe actually not even bad, but nevertheless you end up with all those Besides, I'm currently preparing a discussion with a more modern C#-like syntax. Here a "prototype" static int Foo(object obj)
{
return when (obj == null) with (default)
Debugger.Log("Calling Foo with 'null' object?");
} |
Great, so you have reached the "green" stage of "red, green, refactor". So the next step is: refactor. Rewrite that code, getting rid of all those |
I don't have enough time for that! True! Period! Code I write is done when it works, then the next issue must be solved. And like me there are thousands of thousands of programmers that do not work in a bigger team... @DavidArno : why 👎 ? It's a fact! |
I now rather go with my proposal #453 "Conditional branches, |
Because it's not a fact. Unless you are writing throw-away code that you'll never revisit, your "I don't have time" attitude means you are simply choosing to incur technical debt by not improving your code as you write it. That technical debt then will never be paid off as you will forever be fighting with bad code you wrote before and so will have even less time to make good the new code. And you will never escape that downward spiral until you stop saying "I don't have enough time for that!" and start saying "I will make time for that". Thus the 👎 |
@DavidArno is saying what I was thinking but didn't say. |
@jnm2 @DavidArno Maybe you are coding in a bigger team. I studied economic computer science, too, and from the theoretical point or practical point in team projects I am absolutely with you! But as a freelancer currently I sometimes write some tools here and there for customers and others, besides other work. When they are done, I simply do not have more time to improve the coding, that time wouldn't get paid anyhow. Please respect that. Thanks! |
@lachbaer I respectfully disagree with you when it comes to the practical, real world. If you don't have time to refactor as you go, you end up missing crucial implementation issues. If the project gets beyond a very small size, you start to have architecture issues. These things cost more money than you save by avoiding refactoring. I speak as a primarily lone programmer. Believe me, I've been in situations where I just wanted to ship and felt like I had no time to clean up and design better. I learned the hard way. |
@jnm2 I do refactor a lot. But not to the degree that is mentioned here sometimes. I even started some projects with "a bigger picture" in mind, just to end up starting over with a more "streamlined" version, meaning lesser classes and dependencies - just to get finished. The "bigger picture" were certainly the better, but it simply took too long to finish. |
Me, too. But also the other way round 😉 Guess, I've seen both sides of the coin. 😜 |
@lachbaer More streamlined is typically better than guessing at a bigger picture when you only have guesses. I don't think that kind of thing is what people are talking about in this thread. The discussion is about not liking to see |
Agreed. But it is SO ugly! At least Meanwhile I even like There is only one exception, being |
@HaloFour Thanks for the link! 😃 As I previously said, I don't feature this "Discosal" any more. |
Closing, as this proposal is no longer supported by its author. |
@deaddog @Pilchie @zippec @gafter @HaloFour
Which will become:
I even want to make it: |
You can already do this today:
|
@MohammadHamdyGhanem This issue has been closed. If you have a fleshed out proposal, i would recommend creating a new issue. |
@CyrusNajmabadi |
But
I'm not used to use the On other hand, one can use many |
For example, I can't use
because it will break the loop after first iteration even both functions return null. The following code is not equivalent to the previous one:
But this would be:
|
@MohammadHamdyGhanem This issue has been closed. If you have a fleshed out proposal, i would recommend creating a new issue. |
I just found following code snippet on https://msdn.microsoft.com/en-us/magazine/dn802602.aspx that lead me to the idea of a null-conditional (yield) return statement.
Instead a shorter variant would be
(I really dislike the heavy occurences of
== null
and!= null
)The text was updated successfully, but these errors were encountered: