ATBG: string extensions and const fields

I love bugs. (No, not like that.) It's always interesting to see how things go wrong; as a language designer I want to learn how to make languages less bug-prone, and as a creator of static analysis tools, I want to learn how to detect hard-to-find-but-real bugs.

As I mentioned a while back, we're starting a new series on the Coverity Development Testing blog to share knowledge of interesting bugs, language quirks and so on. The first episode of Ask The Bug Guys is posted now. In this episode I take on two questions: first, why can't you declare a const field of type parameter type? And second, why does overload resolution sometimes choose an unexpected method when an extension method on strings is available? Thanks to contributors Marcin and Adam for two interesting questions.

If you have questions about strange behavior in your C, C++, C# or Java programs, please email your questions (along with a concise reproducer of the problem) to TheBugGuys@coverity.com. We’ll be posting our next set of responses in about two weeks.

(And speaking of Coverity, I was pleased to see this morning that Coverity is #73 on Outside Magazine's "100 Best Places to Work" list. Indeed, we computer types do occasionally go outside! I never thought I'd get a photo of my hat on Outside Magazine's web site, but stranger things have happened. You can see my Tilley Endurables T3G hat in the background there.)


And with that, I'm taking a vacation from blogging for a month. I'll be relaxing on the beaver-shark infested shores of Lake Huron for two weeks in August and then busy with other projects for a couple of weeks after that. We'll pick up in September. Have a lovely rest of your summer and we'll see you for more fabulous adventures in coding in the autumn.1

  1. Substitute winter and spring for readers in the southern hemisphere of course.

11 thoughts on “ATBG: string extensions and const fields

  1. Regarding the first question, it looks to me like it should occasion a review of the whole spec for the terms "reference type" and "reference-type" both, and work out whether they should be the "reference-type" from the grammar or the "reference type" that can be either a "reference-type" or a type-parameter known to be a reference type. Then the term "reference-type" would clearly exclude type parameters, which is consistent with the grammar.

    Is that what you meant by clarifying the spec?

    Also, what it the point of allowing reference types to be const, if the only allowed value for most such types is null? Is it a wart that opens the door to const strings, without special-casing that bit of the grammar to be specific to strings?

    • That is what I meant by clarifying the spec, yes.

      As to the usefulness of the feature: were type parameter consts useful, one imagines that the bug would have been noticed at some point closer to 2005 than to now. :-) As to whether reference type consts being restricted to null or strings is useful, it is occasionally useful to be able to say something like const LinkedListNode EmptyList = null;, but it's not exactly a feature one gets that enthusiastic about.

      • Default parameter values for reference types are required to be constants, and even if `null` is the only available constant that's better than not having any available.

  2. A month is too long for readers ..

    by the way, there're four hats in the photo, three are in the background .. I guess this is your => http://wp.me/a3CcgL-3
    googled for it, found a similar on Amazon.com, and it sells for $74 .. an expansive(expensive) hat!

    • Indeed, the Tilley Endurables T3G hat is the finest sailing hat in the world; the green underbrim reduces glare, it floats, it ties on, it repels rain, it has a pocket in the crown, it will be replaced for half price if lost and free of charge if it wears out. (I have worn many out, but it took some doing; I've been wearing this model of hat for over twenty years and I am extremely hard on my hats.)

      They make many other fine travel and adventure clothing options as well. I've got several pairs of their shorts that I quite like.

  3. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1412

  4. Speaking of extension methods (warning: this is a tangent), I have ALWAYS wondered why you can't create static extension methods for static classes.

    Case in point: The File.Delete() method is a static method on a static class that is quite useful for deleting files. Except it has some annoying "features", such as throwing an exception if the file doesn't exist (really?) and of course failing on read-only files (makes sense). I want to create a ForceDelete() method that I can access via File.ForceDelete() -- seems reasonable -- which succeeds if the file doesn't exist (after all, it's not there either way, right?) and which also works even if the read-only flag is set. But instead I'm forced to create my own static class ("FileEx") and put the method there. Bleh.

    Is there some good, sound, fundamental reason for not allowing static extension methods on static classes that I'm missing? Just curious.

    • One of the big advantages of extension methods is that they allow the operand of even a static method to be specified before anything else. Such advantage would be unavailable with "static extension methods". More useful, I would think, would be allowing a scope to start with a directive like `using class Math;`, and allow static members of that class to be used as though they were in the current scope (so one could say `Sqrt` rather than `Math.Sqrt`). If such things could be limited to the scopes where they were needed, namespace clutter would be avoided in places where such declarations weren't helpful. but visual clutter could be avoided in places where they were.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>