-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Function signature bikeshed #6
Comments
I think being able to use it as a direct tag is quite useful. Imagine an API like: function doSomething(tag = String.cooked) {
return tag`special string ${}`;
} obviously all of that is super contrived, but hopefully it illustrates the utility of having an "identity" tag function that can be used as a default value when no other tag is provided. |
While I personally have only had the need for this in the delegation cases, the syntactic tag case is actually what specifically led me to write something up: seeing someone advising folks to alias I'd encountered this practice once before and it seemed like if multiple people have stumbled on this "solution" - both times not aware of its consequences for escape sequences - then it's a bit of a footgun as-is for raw to stand up there all alone. It's understandable why folks don't realize what I wouldn't expect a feature to be designed around concerns like "I want to give my editor a signal about how to highlight this", but I think those examples hint at particular dev intuitions which would be better served by a "real" tag. |
Okay, I was under wrong impression then. I'll update the issue |
Strongly on the "tag signature" bandwagon, for the reasons already given. In particular, if the name |
I'd prefer the two-arrays signature. The "identity" use case makes no sense in most cases - it's better to use just a literal, for the "cooked" use case, arrays should be changed, so makes no sense to accept a tag - it's an additional load on the call stack and the spread operator can be just forgotten. |
I don't think it is particularly meaningful overhead that it should be specifically designed to prevent anyone from ever using it that way. And I don't think we should make things different for the sake of making them different. |
Splitting this conversation off from #1 since I think it might generate a fair bit of conversation.
I'm going to use TypeScript syntax in other to describe the function signatures, along with the
TemplateStringsArray
type defined in TypeScript:I'm going to make a couple assumptions from the motivation of this proposal:
(Update: People do find this useful)String.cooked
as the direct tag of a tagged template is not useful.String.cooked
will primarily be used to implement other tag functions. (Update: This is probably still true)Tag signature
Neutral: Potentially encourages use ofString.cooked
as a tag directly, even though thats probably not useful.Two-arrays signature
Neutral: Make usingString.cooked
as a tag impossible, discouraging potential incorrect usage.String.cooked
directly as a tag impossibleOther signatures
Feel free to suggest other signatures, please include any pros / cons.
The text was updated successfully, but these errors were encountered: