Skip to content
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

Default null constructor #2292

Closed
ghost opened this issue Mar 4, 2019 · 26 comments
Closed

Default null constructor #2292

ghost opened this issue Mar 4, 2019 · 26 comments

Comments

@ghost
Copy link

ghost commented Mar 4, 2019

I suggest to allow us to define a default null constructor method inside classes and structures:

class Foo()
{
   public Foo(int x, int y)
   {
        // ……
   }
  
  Foo() default() => new Foo(1, 2)
  
}

This default null constructor can be called when the default keyword is used. If it doesn't exist, the default keyword works as usual, so nothing will be broken.

    var f1 = default(Foo);
    Foo f2 = default;

Also, default null constructor can be called if the ! or ? is used with an object that is null:

    Foo f = null;
     var x = f!.x;  // 1

If there is a problem with the ! or ? we can use a new symbol: x = f??.x or any other suitable notation.

This can save us a lot of code needed to initialize the null objects. the ? mark can prevent some exceptions, but the resulting null from the overall expression can cause exceptions in next lines, so in many cases, this doesn't eliminate the need for if != null statement somewhere. If there is a default null constructor, it can control the behavior of this situation in one place, either by reinitializing the null object, or throwing an exception with a specific message other than object null message.

Maybe there are other useful usages of such a default null constructor you can suggest.

@YairHalberstadt
Copy link
Contributor

Can you give actual real life examples of where this would be useful?

Eg. What classes would it makes sense for, what are the existing alternatives, what are their limitations?

Thanks

@HaloFour
Copy link
Contributor

HaloFour commented Mar 4, 2019

Considering that such an "operator" could only ever be useful in very specific cases when you know the actual type that you're trying to "default" I don't see why there needs to be a language feature for this. Just add a static method named "Default" and be done with it.

@ghost
Copy link
Author

ghost commented Mar 4, 2019

@HaloFour
How can a static method help with f??.x which will call the default null constructor if f is null?

@HaloFour
Copy link
Contributor

HaloFour commented Mar 4, 2019

@MohammadHamdyGhanem

How can a static method help with f??.x which will call the default null constructor if f is null?

It wouldn't, nor should it. This isn't a race to make the language unreadably terse.

@YairHalberstadt
Copy link
Contributor

YairHalberstadt commented Mar 4, 2019

@MohammadHamdyGhanem

You open a lot of issues on this repository. Probably more than any other single individual. At the same time, very few of the issues are well received - most recieve far more downvotes than upvotes.

This suggests that their is a disconnect between how you want the language to evolve, and how the majority of people on here want it to evolve.

Continuing to open more issues will lead to you getting more frustrated as your issues are rejected, and participators in the repository getting more frustrated as they are inundated with large numbers of issues which are not going to be acted on. This isn't helpful for anyone.

Can I suggest a more useful approach might be to discuss your ideas on https://gitter.im/dotnet/csharplang before posting them here. Gitter provides a more informal venue, which is more appropriate for discussion. I think many of your ideas are hinting at useful questions, but the solutions are often not in the spirit of C#. Hopefully if they are discussed on gitter first, it might be possible to refine your suggestions before posting them here, and that way it will be much likelier they will be supported and implemented.

I very much hope you do not take this suggestion as an insult. I think you have some very valuable things to contribute to the discussion here, but I feel that they need a bit more working on before you post them, and gitter may be the correct place to do so.

@masonwheeler
Copy link

@HaloFour

Considering that such an "operator" could only ever be useful in very specific cases when you know the actual type that you're trying to "default" I don't see why there needs to be a language feature for this.

This, or something like it, could be useful in conjunction with non-defaultable types. The biggest problem with that proposal is the one @YairHalberstadt pointed out, that there are commonly-used places where you need a default, such as arrays. (And all of the standard collections, which are backed by arrays in one way or another.) If there were a way to define a custom default, that would fix that. (It would probably require CLR support rather than language-level support, but that's not necessarily a bad thing.)

@TPFInferno
Copy link

@HaloFour

Considering that such an "operator" could only ever be useful in very specific cases when you know the actual type that you're trying to "default" I don't see why there needs to be a language feature for this.

This, or something like it, could be useful in conjunction with non-defaultable types. The biggest problem with that proposal is the one @YairHalberstadt pointed out, that there are commonly-used places where you need a default, such as arrays. (And all of the standard collections, which are backed by arrays in one way or another.) If there were a way to define a custom default, that would fix that. (It would probably require CLR support rather than language-level support, but that's not necessarily a bad thing.)

@masonwheeler

Arrays don't have their size determined until instantiation though. You can't forward declare an array with a set size. How would you default the size of the Array?

byte[] blob = default;

How would you resolve that? Would it even be beneficial to set some arbitrary value to be used as a default?

@masonwheeler
Copy link

@TPFInferno I'm not quite sure I understand what you're asking. If you default the array itself, you end up with a null value assigned to a variable of type byte[] (and no one's considering byte as a non-defaultable type anyway; let's pretend you meant type MyStruct[]) and so it has no elements that need to be filled in with defaults.

@Austin-bryan
Copy link

No, because people will expect default to return null for reference types. They are not expecting it to allocate memory and call methods, etc., therefore there would be preformance hits where they are not expecting it.

@CyrusNajmabadi
Copy link
Member

Can I suggest a more useful approach might be to discuss your ideas on https://gitter.im/dotnet/csharplang before posting them here. Gitter provides a more informal venue, which is more appropriate for discussion. I think many of your ideas are hinting at useful questions, but the solutions are often not in the spirit of C#. Hopefully if they are discussed on gitter first, it might be possible to refine your suggestions before posting them here, and that way it will be much likelier they will be supported and implemented.

@MohammadHamdyGhanem i can't ++ this enough. Many many times people have suggested that you use Gitter as a more appropriate medium to first flesh out your ideas. I think there is often a kernel of a good idea in all of them. But you often first go straight to Github, and then dont' engage with the issues in a manner that would lead to the most success. But working with the community first, it will help you get a better understanding of the area, and will help you create a better issue that you can then petition the language for.

I really hope you listen to this advice, as it seems to be something that will give you the greatest chance of success. You can continue to ignore it. however, if you do, don't be surprised if your suggestions don't seem to go anywhere.

@TPFInferno
Copy link

@masonwheeler

I meant actually defaulting the array. I must have misinterpreted your post. Unless what you mean is something like this:

MyStruct[] collection = new MyStruct[5];

Where the instantiation of the array would automatically utilize the custom default to initialize the elements of the array. I can kind of see that being useful, but I think I agree with @willard720 in that if my array is an array of reference types, most people would expect the array to be initialized with null elements.

@masonwheeler
Copy link

@TPFInferno Yes, that's what I mean. And yeah, for reference types this doesn't make much sense, but it would be very useful for value types.

@ghost
Copy link
Author

ghost commented Mar 4, 2019

@masonwheeler
My idea doesn't affect this:
MyStruct[] collection = new MyStruct[5];
The defualt null constructor will never be called unless one uses the default keyword or the ?? symbol as I described. So, Nothing will break developer expectaions. That code would be:
MyStruct[] collection = default (new MyStruct[5]);
or something like that, to populate each array cell with the default value.

@ghost
Copy link
Author

ghost commented Mar 4, 2019

@CyrusNajmabadi:
No, thanks. If you found unuseful issues of mine, please close it.

@CyrusNajmabadi
Copy link
Member

@CyrusNajmabadi:
No, thanks.

I honestly don't understand this attitude. There is an active and engaged community where you could both discuss your issues and refine them to make them more likely to get accepted. You don't seem to want to engage with that community at all, even if it would help out a lot with your proposals. Given the nthusiasm you seem to have had toward opening language suggestions, i would honestly think you'd want them to have the greatest chance of success. But you seem to want to avoid that for reasons that never seem clear to me.

If you found unuseful issues of mine, please close it.

I'd rather see them change into good proposals that can succeed.

@ghost
Copy link
Author

ghost commented Mar 4, 2019

@CyrusNajmabadi:
gitter style is not suitable to the resolution I'm using with my 24 inch screen which is far from me more than 2.5m to protect my eyes! The gitter's font is too small, and when I increase the zooming ratio of the browser, panes become smaller and text disappears. I have to use the magnifier which moves with the mouse pointer. It is a pain for me!
Besides, I don't like chatting in general, because it eats time, and is less organized that a forum discussion.

I don't like to engage in personal arguments, so I always ignore any thing not about the issue.
I feel you are want to suppress any different voice. I said once that any idea can lead to unexpected result. For example, the #1547 proposal which you argued against hard, led me to the dotnet/roslyn#26998 proposal which you implemented yourself (by the ay, I will never write any structure by hand. I will write the fields in a tuple and generate the full structure from it. Thanks :) ).
But, all the debate in #1547 could be terminated at once if you get my purpose and pointed out that can be done by #423 , which Halofour did today after I suggested another approach to the issue that remind him of #423.
So, could we please focus on ideas not on persons?

@CyrusNajmabadi
Copy link
Member

Besides, I don't like chatting in general, because it eats time, and is less organized that a forum discussion.

Then i imagine you will keep your current success rate. If you're ok wth that, so be it. I tried to help :)

@yaakov-h
Copy link
Member

yaakov-h commented Mar 4, 2019

Besides, I don't like chatting in general, because it eats time

So our time as the expense of yours, then? Because:

So, could we please focus on ideas not on persons?

All of your proposals I've seen so far have not made very compelling cases. Sometimes they're poorly structured, or unclear, or don't consider variations, arrays, or other edge cases.

From this end it seriously looks like you have a fleeting idea while coding and immediately run for the "New Issue" button.

It's then up to everybody else to analyse, discuss, and if honestly expect these ideas to be implemented, LDM discussion, implementation and so on.

As it stands now, all of our time(s?) versus a little bit of yours is a very selfish tradeoff.

Please, take the time to flesh out your proposals and provide compelling use cases, explain new syntax, new keywords, re-used keywords, how new syntax would be lowered into equivalent old syntax or IL, etc. Gitter or other C# communities can help with that. (Here could as well, in theory, but people tend to have lower tolerance for "raw" proposals.)

@CyrusNajmabadi
Copy link
Member

Additionally, many of your proposals fall into the: The language already has a solution here (which you were unaware of). It would be much more efficient, and much less noisy, to just go ask gitter: "hey all! i find myself writing this pattern a lot. Is there a simpler way to do this in the language that i'm not aware of?"

@ghost
Copy link
Author

ghost commented Mar 4, 2019

@yaakov-h
Please differentiate between a chat and a discussion, and you will get the answers to your all points :)

@CyrusNajmabadi
Copy link
Member

@yaakov-h
Please differentiate between a chat and a discussion, and you will get the answers to your all points :)

You will get better results with a different approach than the one you are currently taken. The ball is in your court if you wish to take that route. You seem to not want to. So you should potentially consider that in the future if you continue to see no progress made whatsoever on your issues.

@Unknown6656
Copy link
Contributor

Unknown6656 commented Mar 4, 2019

.............................. has he gone?
@MohammadHamdyGhanem is now marked as @ghost as far as I see.

I think that we now need a moderator/[Member] in order to clean up (read: read-through and potentially close) his open proposals/issues......

@CyrusNajmabadi
Copy link
Member

@Unknown6656 I think @MohammadHamdyGhanem closed many of them today.

@Unknown6656
Copy link
Contributor

Hm... I still can see that a few of them are open.....
Of course I do not want to judge to harshly but I think that it is rather safe to close them all. This would rather clean up the current repo (at least concerning some of the issue-background-noise).
If someone wants to re-visit his suggestions they can still comment or open a new issue.

@CyrusNajmabadi
Copy link
Member

Ah, fair enough. I agree with you. Perhaps @tannergooding might be able to help out here?

@YairHalberstadt
Copy link
Contributor

Closing as OP no longer has an account on github, and this proposal has been fairly poorly received

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants