Problem Statement

easyjson currently hardcodes the 'g' format specifier in strconv.AppendFloat() calls for all floating-point serialization. This causes issues for financial applications and other use cases where decimal notation is required instead of scientific notation.

Current Implementation:

• File: jwriter/writer.go
• Lines:
  • https://github.com/mailru/easyjson/blob/master/jwriter/writer.go#L244
  • https://github.com/mailru/easyjson/blob/master/jwriter/writer.go#L254
  • https://github.com/mailru/easyjson/blob/master/jwriter/writer.go#L264
  • https://github.com/mailru/easyjson/blob/master/jwriter/writer.go#L274
• Code: strconv.AppendFloat(w.Buffer.Buf, float64(n), 'g', -1, 32)

The hardcoded 'g' format can produce scientific notation (e.g., 1.5e-6 instead of 0.000001), which breaks compatibility with systems expecting decimal notation.

Existing Attempts

1. PR Avoid scientific notation #356 (alpacahq): Proposed hardcoding 'f' format - breaks backward compatibility
2. PR feat: add float_format flag #367 (rhnvrm/zerodha): Configurable flag approach - maintains backward compatibility

Proposed Solutions

Option 1: CLI Flag (zerodha fork)

Add -float_format CLI flag that:

• Defaults to 'g' (maintains backward compatibility)
• Allows users to specify 'f' or other strconv formats
• Implementation similar to the zerodha fork

Based on the zerodha fork analysis, the changes would be:

1. jwriter/writer.go: Add FloatFmt string field to Writer struct and floatFmt() helper method
2. easyjson/main.go: Add CLI flag parsing and pass format through generator options
3. Generator: Update code generation to use the configurable format

Option 2: Struct Tag

Add floatfmt struct tag for field-level control:

type Price struct {
    Value float64 `json:"value,floatfmt=f"`
}

(Needs feasibility check)

Option 3: Runtime Configuration

Package-level variable for default format that can be overridden via some generated method.

(Needs feasibility check)

Use Cases

• Financial applications: Require decimal notation for monetary values
• Scientific computing: Need specific precision control
• API compatibility: Must match existing JSON parsing expectations
• Data interchange: Systems expecting non-scientific notation

This is a common pain point for easyjson users, as evidenced by multiple forks and PRs attempting to address it. A configurable solution would:

1. Solve the scientific notation issue
2. Maintain backward compatibility
3. Provide flexibility for different use cases
4. Reduce the need for custom forks

I'm willing to contribute the implementation if there's consensus on the approach.

The CLI flag method seems most appropriate as it follows easyjson's existing pattern of configuration options and doesn't break existing code but it hasn't moved ahead and we have been using this. But I am also open to different approaches as well as long as we can fix this.