render/svg lacks a zero-options to_string sibling — asymmetric with render/png and render/ascii

[nao1215]

Summary

The three renderers under qrkit/render/ are no longer symmetric. ascii and png each expose two entry points — one with default options baked in, one accepting an explicit Options value — but svg only ships the explicit-options variant. Every caller using SVG with default settings has to repeat svg.to_string(qr, svg.default_options()) instead of svg.to_string(qr).

This was probably the right intermediate state when #28 ("expose options builder like the SVG/ASCII renderers") landed for PNG, but it leaves SVG as the odd renderer now.

Current entry points

qrkit/render/ascii
  pub fn to_string(qr) -> String
  pub fn to_string_with(qr, options) -> String
  pub fn with_inverse(qr) -> String
  pub fn to_string_compact(qr) -> String
  pub fn to_string_compact_with(qr, options) -> String

qrkit/render/png
  pub fn to_bit_array(qr) -> BitArray
  pub fn to_bit_array_with(qr, options) -> BitArray

qrkit/render/svg
  pub fn to_string(qr, options) -> String      ← only one entry point

Reproduction

Environment:

• Gleam: 1.15.2
• Package: qrkit@0.4.0

import qrkit
import qrkit/render/ascii
import qrkit/render/png
import qrkit/render/svg

pub fn main() {
  let assert Ok(q) = qrkit.encode("https://example.com")

  let _ = ascii.to_string(q)              // works — defaults baked in
  let _ = png.to_bit_array(q)             // works — defaults baked in
  let _ = svg.to_string(q)                // compile error — missing options arg
  let _ = svg.to_string(q, svg.default_options())  // current workaround
}

Expected

Add a zero-options sibling for SVG so the API shape matches the other two renderers:

pub fn to_string(qr: qrkit.QrCode) -> String {
  to_string_with(qr, default_options())
}

pub fn to_string_with(qr: qrkit.QrCode, options: SvgOptions) -> String {
  // existing body
}

If there's any reason to keep callers explicit (e.g., a forward-compatibility concern with SvgOptions evolving), that could be called out in the docstring — but the convenience form should still exist because it already exists for ascii and png.

Notes

This is the documented-but-mildly-awkward case rather than a bug — the README quickstart shows svg.to_string(qr, svg.default_options()) so the existing behaviour is consistent with how it's marketed. The asymmetry mainly bites people who copy a snippet from the ASCII or PNG section and try the same shape with SVG.

Surfaced during a focused review of the renderer family.