Hacker News new | past | comments | ask | show | jobs | submit login

So it's purely syntactic sugar around concatenating plain string literals and various expressions, it has no relation to print or other I/O, and in case a string comes from input (BTW, I don't see any mention of serious IO besides print for "logging") or from some computation it isn't subject to interpolation.

I don't think limiting string interpolation to enhanced string literals in code (leaving out generic strings) in order to allow static checking is a practically acceptable restriction. For example, logging frameworks meant for long-running application tend to specify message templates in configuration files or databases, possibly hot-reloading them at runtime.




More or less, yes. I may later change it to some type like `Interpolated env` to represent a lazily interpreted string that interpolates the types in env. So "${1u8} and ${2}" would be typed as Interpolated (u8, i32).

I'd like to keep this orthogonal to IO or other specific use cases so that it is applicable to any use case users may have rather than tailored to existing ones. You're also correct there is no real logging framework or anything of the kind except print really. Ante is still in a quite early state and there aren't really any substantial libraries to speak of. As-is, interpolation is really just some nice sugar to make some common operations more ergonomic, like f-strings in python.

I think applications that need their own dynamic interpolation requirements should define their own interpolation to handle their specific needs. It would be unacceptable from a performance and predictability standpoint for example to support the example of loading files into a string and have them interpolated at runtime automatically for all file loads.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: