Requesting more details on the motiviation for two directives

[codehag]

@michaelficarra hi, this is a clarifying question, not an issue. But this looks like the best place to put it.

It is unclear to me how users will use both these directives. I can imagine one of them being used, but seeing them both used for specific cases is escaping me. If I understand correctly, the main difference between these two directives is how they appear as errors? I suspect that the difference of hiding the function for example in the error as anonymous, or removing it entirely, may be missed by most users. In a nutshell, this is what I want to better understand.

In other words, If we have sensitive, do we need hide source? And if so, who are the users of these two cases?

Another concern is the open ended nature in the way that sensitive might be expanded in the future. While there is some description of how it might evolve, it feels risky to give something the green light without knowing what it will entail in the future, and without it having further differentiation from hide source. At the moment it feels like we have a placeholder for future work, rather than fulfilling a user need. Could it make sense to wait on one of these directives, gather more information, and pursue it later?

This may have been answered already, but I couldn't find it in the notes or the slides. If it has, you can direct me there. Thanks!

[michaelficarra]

We are concerned with 4 use cases, serviced by 2 directives:

1. security-sensitive use cases that rely on the confidentiality of one of

   • the source text,
   • the local bindings, or
   • the calling behaviour

   of a function, serviced by the "sensitive" directive

2. polyfills appearing to be built-ins, serviced by the "hide source" directive

3. libraries that do not want consumers of exposed functions/methods to rely on what many consider to be implementation details and not an intentional part of their API, serviced by the "hide source" directive

4. libraries that would like to factor out helper functions without changing observable aspects of their API, serviced by the "sensitive" directive

For your question about future expansion of the "sensitive" directive, see In what ways might the "sensitive" directive expand in the future? in the README. Does that answer your question?

[jorendorff]

@michaelficarra This is very useful. Thanks. I have two follow-up questions:

• In case 1, what does "local bindings" mean?

• How does case 4 differ from case 3?

Thinking aloud: The interests of users in cases 2, 3, and 4 seem very closely aligned. They want some implementation hiding, and all for exactly the same reason: so that functions can serve as an abstraction boundary. They want to retain the freedom to change implementation details without breaking compatibility. (I don't mean to complain that these three cases are listed separately -- quite the contrary, it's great to have fully concrete, human use cases to refer to.)

[michaelficarra]

@jorendorff

In case 1, what does "local bindings" mean?

These are the variables declared within the function. From the README:

if, for example, the Function.prototype.environment proposal made its way into the language, it would not be available for functions marked as "sensitive"

How does case 4 differ from case 3?

Consider the difference between library code that is exposed to consumers, where you do not want them introspecting on the source text, and helper functions used in a library, where you do not want consumers to even know they exist (through stack trace inspection). These two functions have different observability concerns.

[erights]

See tc39/ecma262#1739 (comment)