fmt should show warning
Archos
isn't expecting. This would avoid many errors, especially when you
create regular expressions (as has been seen in another thread).
***
var char = 'a'
var expChar = fmt.Sprintf("^%s+\n", char)
***
chris dollin
> I believe that fmt should show a warning when it gets a type that it
> isn't expecting.
And what expectations does fmt have?
Chris
--
Chris "allusive" Dollin
Peter Bourgon
Sometimes, when you make a programming error, it doesn't necessarily
mean the language should change. It just means you should aim to be a
little more careful.
/$0.02
andrey mirtchovski
Archos
On Sep 3, 6:08 pm, chris dollin <ehog.he...@googlemail.com> wrote:
>
> > I believe that fmt should show a warning when it gets a type that it
> > isn't expecting.
>
> And what expectations does fmt have?
character
See about verbs:
http://golang.org/pkg/fmt/
Archos
On Sep 3, 6:12 pm, Peter Bourgon <peterbour...@gmail.com> wrote:
find it easily. With such errors there is no way to find it so.
Archos
solution would be to add a function in regexp to show the original
expression, or to do public to Regexp.expr
http://golang.org/src/pkg/regexp/regexp.go#L115
Russ Cox
> solution would be to add a function in regexp to show the original
> expression, or to do public to Regexp.expr
It's a problem with any function that accepts a string.
Should they all be required to hand you back the
string upon request? What about things that aren't
strings? I'm sympathetic to running into bugs, but
you're asking to augment a single API with debugging
functionality already present in the programming language.
Variables and print statements already let you replace:
var reg = regexp.MustCompile(fmt.Sprintf(....))
with
func init() {
s := fmt.Sprintf(....)
fmt.Println("COMPILING", s)
reg = regexp.MustCompile(s)
}
Russ
Archos
(functions Print*), but not when is used to return a string (functions
Sprint*) because they're going to masking a possible error/warning,
like has happened on this case.
Archos
On Sep 3, 8:14 pm, Russ Cox <r...@golang.org> wrote:
> > Since it's a problem that can be got in regular expressions, a better
> > solution would be to add a function in regexp to show the original
> > expression, or to do public to Regexp.expr
>
> It's a problem with any function that accepts a string.
> Should they all be required to hand you back the
> string upon request? What about things that aren't
> strings? I'm sympathetic to running into bugs, but
> you're asking to augment a single API with debugging
> functionality already present in the programming language.
> Variables and print statements already let you replace:
should return a boolean to indicate if there was a warning
roger peppe
incompatible with a format character - it's a similar
error to evaluating x.(T) where x is not of type T.
leaving the error in-band only leads to subtle bugs such as the one illustrated
by Archos.
i realise i'm in a minority on this though.
Rob 'Commander' Pike
execute a print statement that's never been executed before. In such
situations it's much better tactics to do what the package does now
than to trigger a panic while reporting an error. In the extreme
case, you're suggesting a panic during a panic.
The real right solution is to find a way for the compiler or some
other tool to help, analogous to - but not the same approach taken by
- the #pragmas in the Plan 9 C compiler.
-rob
Scott Lawrence
This sounds like the sort of thing worth adding to golint, but: does the
compiler do any optimizations on functions like fmt.Printf? If so, it
would be logical to deal with it there.
Rob 'Commander' Pike
Plan 9 C compiler until it's told about the functions by the #pragmas.
I'm not suggesting any plan of action, just noting that when the right
path is clear, even though its route is not, the wrong path is to be
avoided.
-rob
Ostsol
return some "FormatError" or whatever to indicate that the wrong
format verb was used for the argument. An exception would be if
writing to the Writer failed, in which case the problem with
formatting is moot.
-Daniel