Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 01 22:07
    User @CyrusNajmabadi unbanned @VBAndCs
  • May 13 18:16
    @CyrusNajmabadi banned @Korporal
  • Jan 29 18:46
    @CyrusNajmabadi banned @VBAndCs
  • Jan 16 2021 19:06
    @CyrusNajmabadi banned @JuliusRFriedman_twitter
  • Nov 01 2020 06:15
    @CyrusNajmabadi banned @juliusfriedman
  • Jan 31 2019 21:39

    gafter on master

    Propose Feb 11 agenda (#2187) (compare)

  • Jan 31 2019 21:39
    gafter closed #2187
  • Jan 31 2019 19:42
    gafter edited #2115
  • Jan 31 2019 15:46
    jcouv edited #1565
  • Jan 31 2019 14:51
    yigitgursoy closed #1958
  • Jan 31 2019 13:43
    ichensky closed #2190
  • Jan 31 2019 12:17
    ichensky opened #2190
  • Jan 31 2019 04:38
    MarkPflug edited #2189
  • Jan 31 2019 04:37
    MarkPflug edited #2189
  • Jan 31 2019 04:37
    MarkPflug edited #2189
  • Jan 31 2019 04:36
    MarkPflug opened #2189
  • Jan 30 2019 23:15
    MohammadHamdyGhanem opened #2188
  • Jan 30 2019 20:01
    gafter review_requested #2187
  • Jan 30 2019 20:01
    gafter review_requested #2187
  • Jan 30 2019 20:01
    gafter review_requested #2187
Eyal Alon
@eyalalonn
Yes it worked! thanks! ;)
CyrusNajmabadi
@CyrusNajmabadi
cool :)
sorry about that
Eyal Alon
@eyalalonn
I've added C# as a tag which worked but it wouldn't remove C++ or setup from the tag list and I did sign-out and in again. :D
Might takes time for it to update dunno.
Eyal Alon
@eyalalonn

Is there any reason the compiler can infer the type of TRequest in the following case:

public static async Task AddRow<TRequest>(int tableId, TRequest request)

When calling the method like AddRow(..., new MyRequestObject())

But not partially when there is more than one type parameter like in this this?

public static async Task<TResponse> AddRow<TResponse,TRequest>(int tableId, TRequest request)

The first method does not exist so there is no ambiguity so why can't I just do AddRow<MyResponseObject>(..., new MyRequestObject())?

masonwheeler
@masonwheeler
Because the ambiguity can exist, so type parameters are all-or-nothing. It doesn't look at this and say "here's a reference to something with two type parameters and there's only one filled in, so let's see if we can infer the other one." It says "here's a reference with type parameters. Let's see what that matches. Only one match, it has two type parameters, the reference only has one. Error!"
Eyal Alon
@eyalalonn
@masonwheeler It comes down to this feature isn't implemented but the question is whether there is something blocking them from adding something like that?
masonwheeler
@masonwheeler
That's actually not the way the language designers think about it. It's not a "feature that isn't implemented;" it's a thing that is not a feature of the language. The question to ask is not "why isn't this there?" but "should this be there at all?"
Is there a compelling reason why they should devote limited resources to making that, specifically, into a feature rather than all the other things they could be working on instead?
Eyal Alon
@eyalalonn

@masonwheeler

It's not a "feature that isn't implemented;" it's a thing that is not a feature of the language.

What are you trying to say here?

The question to ask is not "why isn't this there?" but "should this be there at all?"

Asking why it can do this and not the other isn't quite as asking why it isn't there. :) and yes I think that more type inference especially when it comes down to generics is useful.

Is there a compelling reason why they should devote limited resources to making that,
specifically, into a feature rather than all the other things they could be working on instead?

Yes because this is exactly how things work. I agreed to do something so I absolutely must prioritize everything I agree on to the next release over existing features but dunno that's something the LDT needs to decide I only asked a simple question, I didn't propose anything.

masonwheeler
@masonwheeler

What are you trying to say here?

Exactly what I said. An unimplemented feature is something the team has decided to do but hasn't implemented yet. This is something that has not been decided. It is not a feature, unimplemented or otherwise.

Asking why it can do this and not the other isn't quite as asking why it isn't there.

The answer to "why it isn't there" is always the same: because nobody has built it. That may sound glib but it's quite literally true. (See above, re: limited resources.) There has to be a very good reason to spend time and effort designing, speccing, coding, testing, and documenting a new feature. Minus 100 points is a good article for understanding the team's perspective on it; I'd recommend familiarizing yourself with the principle it explains if you want to ask for new language features.

Eyal Alon
@eyalalonn
@masonwheeler I'm familiar with the concept. I've been here for many, many years but again I'm not complaining or proposing them to add it as a feature; otherwise, I'd posted a proposal.
HaloFour
@HaloFour
There are a few out there. I get the sense that the language team might be more interested in existential/associated types rather than expanding generic inference in those cases. Same thing, basically, but the other generic parameters aren't really part of the signature.
Eyal Alon
@eyalalonn
@HaloFour Thanks.
masonwheeler
@masonwheeler
Anyone know why the latest version of Visual Studio has stopped showing me grayed out usings that aren't used in the file, but only for some projects and not others?
CyrusNajmabadi
@CyrusNajmabadi
File issue. Sounds like a regression.
masonwheeler
@masonwheeler
Is it possible to put an Attribute marked as [AttributeUsage(AttributeTargets.Constructor)] on the autogenerated constructor from a record?
Joe4evr
@Joe4evr
@masonwheeler doesn't look like it from a little rudimentary experimentation, see if there's an open discussion
HaloFour
@HaloFour
@masonwheeler Where does Delphi have inherited constructors?
masonwheeler
@masonwheeler

@HaloFour The entire language. If you define a constructor on a base class, you can use it on any of its descendants. The place it gets really useful, though, is when you start working with virtual constructors. You can call a virtual constructor with a metaclass reference, pass in the parameters, and get an instance of the class in question.

As I mentioned on the Github discussion, this was largely put in place to support form deserialization. The DFM (form data) files have class names in them, and the RTTI system has something functionally equivalent to a string->metaclass dictionary for all of the Component types used in your program. So you take your class name, get a metaclass from there, invoke the virtual constructor, and you have a Component-typed reference whose actual type is the class you wanted. Use RTTI to fill in the properties, then repeat recursively on all the child components until you have your whole form.

HaloFour
@HaloFour
So that's specifically related to constructors marked as virtual, otherwise it works like other OOP languages where the derived class can call the base constructor but you can't create the derived class by calling the base constructor.
masonwheeler
@masonwheeler
Nope. :point_up:
If you define a constructor on a base class, you can use it on any of its descendants.
HaloFour
@HaloFour
Even if it defines its own constructors that require additional parameters?
masonwheeler
@masonwheeler
type BaseClass = class
   constructor Create(value: integer);
end;

DerivedClass = class(BaseClass)
   constructor Create(value1: integer; value2: string);
end;

...

MyObj := DerivedClass.Create(5); //this is perfectly valid
HaloFour
@HaloFour
Wow, that feels so wrong
masonwheeler
@masonwheeler
It's not what you're used to.
And it's not particularly idiomatic.
But the language specification does not forbid it.
HaloFour
@HaloFour
Does the compiler warn about it?
Was kinda hoping Oxygene had an online playground but it doesn't seem to
masonwheeler
@masonwheeler
I don't think so. It's been a while since I've worked with Delphi, and I know some people were asking for warnings on scenarios like that, so more recent versions might, but I wouldn't bet on it.
Oh, well you definitely can't do that in Oxygene. It's a CLR language and that's forbidden by the CLR.
HaloFour
@HaloFour
Sure, but I understand that it emits stuff to smooth over the differences
Like metaclasses
masonwheeler
@masonwheeler
true
HaloFour
@HaloFour
That would drastically affect how I might design object hierarchies, I'd probably intentionally avoid inheritance in more cases, especially if the only safeguard would be to override and throw.
masonwheeler
@masonwheeler
Some of it's just philosophy. Why do you need a "safeguard"? If someone else inherits from your class and gets the constructors wrong, that's on them, not you.
HaloFour
@HaloFour
I find it very common to want to define a base class that requires additional state at construction.
The inability to force the correct call on the consumer feels very wrong to me
And without overriding and throwing a consumer could very easily accidentally create an instance in an incomplete state.
masonwheeler
@masonwheeler
🤷‍♂️ Different language, different idioms. "Could very easily," yes, but in practice it doesn't tend to happen.
HaloFour
@HaloFour
Must rely a lot less on constructors
But this is why virtually no other OOP language has such a thing.
"Construction is separate from consumption"
Anyways it is interesting to hear that there are languages that don't follow that approach. I recall Delphi being around in the mid 90s but I knew almost nobody who actually worked in it. I recall it being stupidly expensive.
I used to keep in touch with a dev who worked on the Oxygene compiler but we haven't chatted in a long time
masonwheeler
@masonwheeler
Yup. That's what drove it into the ground. Corporate refused to acknowledge that it couldn't effectively compete with free versions of .NET and Java and Python at a high-3-figures minimum-SKU price point.
HaloFour
@HaloFour
As I recall it, the minimum SKU wasn't exactly sufficient for business app development either. I recall Borland's site implying that if you needed DB connectivity that the price was several thousand.
masonwheeler
@masonwheeler
Yup. It's gotten better over the years, but... too little too late.