Should we deprecate dynamic?

[hughesjs]

C# is a strongly typed language. Having dynamic really just serves to enable developers to be lazy.

I can't think of any places where using dynamic is actually preferably to using a generic.

I'm open to having my mind changed on that though if anyone has any convincing examples.

If there are none, why don't we deprecate it?

[CyrusNajmabadi]

We are not going to deprecate this as it would break huge programs around the world.

is actually preferably to using a generic.

I don't know what this means. 'dynamic' is for dynamic programming. Where the type is not known. Generics are for generic programming, where the types are statically known, but you want code to specialize for each potential static type.

Note: you are free to deprecate any language feature you want in your own projects. Writing an analyzer here would be about 5 minutes of work. This would be the only thing we would support wrt deprecation.

[hughesjs]

I don't think your first statement isn't entirely true, it would only prevent them from using newer language versions, they'd be fine on old versions no? That being said, I did expect this answer.

As for your second point, I understand they're different concepts, but I can't think of a situation where you genuinely don't know and can't know the type.

[CyrusNajmabadi]

I don't think your first statement isn't entirely true, it would only prevent them from using newer language versions,

There's the definition of breaking them. They upgrade, they can't compile. That's a break.

but I can't think of a situation where you genuinely don't know and can't know the type.

Trivial cases include hosting. You run scripts in an environment where a host provides a dynamic host object to interact with it with.

[TahirAhmadov]

dynamic is useful in some scenarios, and chances are you and most developers don't encounter those scenarios. And that's fine - C# is a powerful language and supports many workloads, other than dynamic, there are things like unsafe, etc. I, for one, almost never use any of these features, and that's fine. There are many others who do.

[Richiban]

dynamic has perfectly legitimate uses, such as database access or JSON deserialisation. If you see programmers misusing the feature then that behaviour needs to be a addressed; there's no need to remove the feature because of it.

[theunrepentantgeek]

I can't think of any places where using dynamic is actually preferably to using a generic.

I've used dynamic to optimize performance by deferring the selection of a method overload until runtime. Normally, overload selection is done at compile time.

My specific examples are in complex object domains that would take far more time to explain, but here's a simple illustration of the idea.

We can define a minimal interface for a printer as

public interface IPrinter
{
    void PrintPage(Bitmap image);
}

with implementations including PCLPrinter, PostscriptPrinter, FaxPrinter, EmailPrinter, and so on.

And then we can define printable documents:

public interface IPrintableDocument
{
    void PrintTo(IPrinter printer);
}

with implementations including HTMLDocument, MarkdownDocument, PostscriptDocument, and so on.

Anywhere in my code, I can then print any document:

myDoc.PrintTo(myPrinter);

But, and here's where dynamic is super useful, this will always use the lowest common denominator implementation where each page is rendered as a bitmap image and send to the printer page by page.

Some combinations of document and printer can function in a much more efficient way.

For example, sending an HTMLDocument to an EmailPrinter doesn't need to render the bitmaps, it can just use the HTML as the body of the email. Similarly, sending PostScriptDocument directly to a PostScriptPrinter is far more efficient.

To achieve this efficiency, we start by adding a couple of overloads of PrintTo().

public class HTMLDocument
{
    void PrintTo(EmailPrinter printer) { }
}

public class PostScriptDocument
{
   void PrintTo(PostScriptPrinter printer) { }
}

And then, we use dynamic when sending the document to the printer:

var dynamic dispatchDoc = myDoc;
dispatchDoc.PrintTo(myPrinter);

That's it. As simple as that, and now the most specific overload of PrintTo() will always be used.

[TahirAhmadov]

I'm not arguing that dynamic is useless, but I think in your use case an even more efficient (albeit not by much) implementation is possible with some if(printer is IEmailPrinter emailPrinter) { this.PrintTo(emailPrinter); return; } branches

[CyrusNajmabadi]

That requires manually writing and maintaining all that code. Teh point above is that dynamic dispatch just solves taht entirely. You through the objects at it, and it calls the best option. Yes. You could possibly redo all that it has done and maintain that code yourself, but that's why we have dynamic in the first place. So you don't have to :)

[theunrepentantgeek]

Writing code like that requires all the kinds of documents and all the kinds of printers to be in-scope, which is often undesirable, and sometimes impossible. It also requires implementers to be diligent enough to find all the places where those downcasts have been used and to update them where required.

I guess if you're working on a small monolith that wouldn't be too bad - but in the contexts where I used dynamic in this way, it wouldn't have worked.

[FaustVX]

It looks like to be a very specific use for dynamic, but I really like that.

[CyrusNajmabadi]

Having dynamic really just serves to enable developers to be lazy.

I wanted to touch on this. It's very much the case that lazyness is a virtue. As something of a developer myself, i like it when i can get more done with less effort on my part. Dynamic absolutely helps with that. So calling it (and developers who use it) out for being more effective isn't a good argument for getting rid of this extremely useful feature :)

[hughesjs]

I'm not sure doing away with type safety in the name of getting things done slightly quicker can be used as a blanket statement for "more effective" but I do somewhat take your point

[HaloFour]

Don't forget late-bound COM interop. 😅

[iam3yal]

I'd say it's better to make assumptions that are based on facts rather than assumptions that are based solely on your experience /beliefs and then go on to make claims, just because you don't find a feature interesting or haven't used it yet doesn't mean it should be removed and it certainly doesn't mean you should imply certain things about the group of people that do find it useful and make good use of it. :)

[hughesjs]

Well, seems I'm clearly wrong on this one. Cheers for the input everyone :)