Emulating String.Format compile-time functionality

  • Thread starter Thread starter Rick
  • Start date Start date
R

Rick

With String.Format, if I have an incorrect number of args specified for a
format string, compile fails. How can I implement similar design-time
functionality for my own string functions?
 
Rick said:
With String.Format, if I have an incorrect number of args specified for a
format string, compile fails.

No it doesn't. This compiles just fine for me, but fails at runtime:

---8<---
~$ cat test.cs
class App
{
static void Main()
{
string.Format("{0} {1}", "foo");
}
}

~$ csc test.cs
Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

~$ ./test

Unhandled Exception: System.FormatException: Index (zero based) must be
greater than or equal to zero and less than the size of the argument
list.
at System.Text.StringBuilder.AppendFormat(IFormatProvider provider,
String format, Object[] args)
at System.String.Format(IFormatProvider provider, String format,
Object[] args)
at App.Main()
--->8---

-- Barry
 
Barry Kelly said:
No it doesn't. This compiles just fine for me, but fails at runtime:
<snip>

This is one of my little pet peeves.

This compiles just fine
Console.WriteLine("{0)", 3); // not the mismatched braces

but then you get the dreaded
System.FormatException: Input string was not in a correct format.

I realize that the method call is syntactically correct, but it will
obviously fail at runtime.
It would be nice if the compiler went that extra mile and validated the
format string at compile time.
Obviously, this couldn't be done every time.
For instance, if the format string was dynamic.
But if the format string is a string literal, there is nothing (that I
can see) that would prevent the compiler from "Looking" at the format
string and the argument list.

Maybe in 3.0

Bill
 
This is one of my little pet peeves.

This compiles just fine
Console.WriteLine("{0)", 3); // not the mismatched braces

but then you get the dreaded
System.FormatException: Input string was not in a correct format.

I realize that the method call is syntactically correct, but it will
obviously fail at runtime.
It would be nice if the compiler went that extra mile and validated the
format string at compile time.

I can see the benefits, but I think a compiler should be sticking to
the language specification - and the language spec *certainly*
shouldn't be talking about format specifiers and the like, IMO. That's
the business of the library being used, not the language.
Obviously, this couldn't be done every time.
For instance, if the format string was dynamic.
But if the format string is a string literal, there is nothing (that I
can see) that would prevent the compiler from "Looking" at the format
string and the argument list.

There's nothing language specific about this - I think it would be
quite possible for a tool to run through a built assembly and check
for string literals which are used for format strings. As well as a
knowledge of the current methods taking format strings, you could also
add a decorator attribute to a parameter to specify that it should be
a format string, so that the tool could validate the use of your own
methods as well.

Jon
 
Using Visual Studio without R# would be like going back to C++.

///ark
 
Bill said:
This is one of my little pet peeves.

This compiles just fine
Console.WriteLine("{0)", 3); // not the mismatched braces

but then you get the dreaded
System.FormatException: Input string was not in a correct format.

I realize that the method call is syntactically correct, but it will
obviously fail at runtime.
It would be nice if the compiler went that extra mile and validated the
format string at compile time.

Probably the "best" way to do it would to enable compile-time code
execution of some kind. A little like D's system, perhaps.

I believe something like that is some way out though.

-- Barry
 
Jon Skeet said:
I can see the benefits, but I think a compiler should be sticking to
the language specification - and the language spec *certainly*
shouldn't be talking about format specifiers and the like, IMO. That's
the business of the library being used, not the language.

I know. I know. But we are talking about THE library.
The call IS syntactically correct, and therefore, beyond the job
description of a compiler, but since Console.WriteLine and all of it's
similar cousins are part of the CLR (and commonly used), it would be
helpful to have some means of validating all recognizable format strings
at compile time (or at least before the program ships).

A compiler switch for csc.exe would be nice, but I would be fine with a
separate command line tool.

There's nothing language specific about this - I think it would be
quite possible for a tool to run through a built assembly and check
for string literals which are used for format strings. As well as a
knowledge of the current methods taking format strings, you could also
add a decorator attribute to a parameter to specify that it should be
a format string, so that the tool could validate the use of your own
methods as well.

You have a point, I could probably sit down and write something that
does exactly what I was asking Microsoft to give me for free :^)

Of course, if I wrote it, far fewer people would have access to it (and
it would have a greater chance of being half-assed).

Oh well

Thanks for the input
Bill
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top