Maybe fmt.Errorf encourages
fmt.Errorf("%v %v", false, 42)
Or worse
fmt.Errorf("error %v %v", false, 42)
:-)
On Sun, Dec 30, 2018, 1:07 AM Jakob Borg I would suggest that an error should start with a descriptive string. The
> existing methods encourage this. A fmt.Error as suggested would
I would suggest that an error should start with a descriptive string. The
existing methods encourage this. A fmt.Error as suggested would not, instead
implicitly encouraging things like fmt.Error(false, 42) which is user
unfriendly.
//jb
On 30 Dec 2018, at 09:53, Justin Israel
On Sun, Dec 30, 2018 at 9:26 PM Liam Breck wrote:
> Justin, see docs for fmt.Print(...interface{})
>
Ah true. I forgot about the whitespace formatting versions. I stand
corrected that a fmt.Error would actually perform formatting and would be
consistent with Sprint and Print. My only guess now
Justin, see docs for fmt.Print(...interface{})
On Sun, Dec 30, 2018, 12:15 AM Justin Israel
>
> On Sun, Dec 30, 2018, 7:24 PM Liam Breck wrote:
>
>> What's the rationale for omission of:
>> fmt.Error(a ...interface{}) error
>>
>
> What does it mean for this function to accept a variable
On Sun, Dec 30, 2018, 7:24 PM Liam Breck wrote:
> What's the rationale for omission of:
> fmt.Error(a ...interface{}) error
>
What does it mean for this function to accept a variable number of
arguments when there is no formatting or printing implied by the name of
the function?
> Given
What's the rationale for omission of:
fmt.Error(a ...interface{}) error
Given that other fmt functions come in that variety?
I realize it can be achieved like this, but so can fmt.Errorf
errors.New(fmt.Sprint(...))
Would a proposal to add it be entertained?
Happy New Year to all :-)
--
