3 ms·

Please read the context of my reply again. The Rejected Golang proposal cited by the post I'm replying to. NOT Python's present PEP or any other string that m

Please read the context of my reply again. The Rejected Golang proposal cited by the post I'm replying to. NOT Python's present PEP or any other string that might resolve magic variables (just not literally eval / exec functions!).

zahlman 2y ago
As far as I can tell from the linked proposal, it wouldn't have involved such evaluation either. It seems like it was intended to work fundamentally the same way as it currently does in Python: by analyzing the string literal ahead of time and translating into equivalent explicit formatting code, as syntactic sugar. There seem to have been many misunderstandings in the GitHub discussion.
- mjevans 2y ago
  In that case, I might have misunderstood the intent of those examples. However the difficulty of understanding also illustrates the increased maintenance burden and language complexity.
  - eviks 2y ago
    Unless workarounds to a missing feature have a higher maintenance burden like in this case, and you can't avoid it via learning
    - mjevans 2y ago
      Go's preferred way would probably be something like compute the aliased operations on the line(s) before, then reference the final values. E.G. Adapting https://github.com/golang/go/issues/34174 https://github.com/golang/go/issues/34174 f := 123.45 fmt.Fprintln("value=%08.3f{f}") // value=0123.450 fmt.Fprintln("value=%08.3f", f) // value=0123.450 s := "value" fmt.Fprintln("value='%50s{s}'") // value='<45 spaces>value' fmt.Fprintln("value='%50s'", s) // value='<45 spaces>value' The inline {variable} reference suffix format would be less confusing for situations that involve _many_ variables. Though I'm a bit more partial to this syntax with an immediately trailing %{variable} packet since my gut feeling is that special case would be cleaner in a parser. fmt.Fprintln("value=%08.3f%{f}") // value=0123.450 fmt.Fprintln("value='%50s%{s}'") // value='<45 spaces>value'
paulddraper 2y ago
The proposal cited Swift, Kotlin, and C# which have similar syntax sugar. The proposal was for the same.

zahlman 2y ago

As far as I can tell from the linked proposal, it wouldn't have involved such evaluation either. It seems like it was intended to work fundamentally the same way as it currently does in Python: by analyzing the string literal ahead of time and translating into equivalent explicit formatting code, as syntactic sugar. There seem to have been many misunderstandings in the GitHub discussion.

mjevans 2y ago
In that case, I might have misunderstood the intent of those examples. However the difficulty of understanding also illustrates the increased maintenance burden and language complexity.
- eviks 2y ago
  Unless workarounds to a missing feature have a higher maintenance burden like in this case, and you can't avoid it via learning
  - mjevans 2y ago
    Go's preferred way would probably be something like compute the aliased operations on the line(s) before, then reference the final values. E.G. Adapting https://github.com/golang/go/issues/34174 https://github.com/golang/go/issues/34174 f := 123.45 fmt.Fprintln("value=%08.3f{f}") // value=0123.450 fmt.Fprintln("value=%08.3f", f) // value=0123.450 s := "value" fmt.Fprintln("value='%50s{s}'") // value='<45 spaces>value' fmt.Fprintln("value='%50s'", s) // value='<45 spaces>value' The inline {variable} reference suffix format would be less confusing for situations that involve _many_ variables. Though I'm a bit more partial to this syntax with an immediately trailing %{variable} packet since my gut feeling is that special case would be cleaner in a parser. fmt.Fprintln("value=%08.3f%{f}") // value=0123.450 fmt.Fprintln("value='%50s%{s}'") // value='<45 spaces>value'

paulddraper 2y ago

The proposal cited Swift, Kotlin, and C# which have similar syntax sugar. The proposal was for the same.