i still think the answer to where parameter decorators fit in is that we do not have parameter decorators

The way TS does parameter decorators today is it passes through a __param decorator on the method that essentially adapts it to a method decorator, so Metadata is still associated with the class

rbuckton: i am not interested in the mechanics of it until we decide it's actually a good idea?

That’d be simplest possible API here, though it’s a bit odd

VSCode is a TS project?

That’s something of an understatement, is it not, since TS and VS Code both originate in the same lab?

I think the simplest API for metadata is to have an associated object which lives on the context, which is created per class definition, and which is passed to every decorator within the class. if a decorator wants to expose the metadata to the class, a class-level decorator add a symbol to the class which exposes the context object.

we have pretty divergent personal understandings of "decent subset" i think

not even the GObject = makeGObject() bit, with that design

I think the simplest API for metadata is to have an associated object which lives on the context, which is created per class definition, and which is passed to every decorator within the class. if a decorator wants to expose the metadata to the class, a class-level decorator add a symbol to the class which exposes the context object.

encapsulation should be the default, not opt-in

pzuraq: even for static fields?

What are the validation use cases where the validator piece wouldn't have access to the internal state of the decorator?

Metadata use cases:
DI, plugin/extensibility, ORM, WSDL/ws*, REST discovery/routing, FFI/Marshaling (esp parameters), serialization control (binary, JSON, XML), validation/contracts, RTTI, debugging (watch/locals window control, stepping behavior), proxy/membrane permeability,...

man we have pretty different definitions of "untenable", rbuckton

man we have pretty different definitions of "untenable", rbuckton

then I guess I'm leaning toward caching the return value but ignoring passed arguments

I don't understand why we would break with precedent

those are some of the longest threads I've participated in

The problem with n-argument memo is that it has to hold the arguments for repeated calls. 0-arg memo is easier, but then it isn't really a memorize function

0-arg memo would be a core use case of memo, I figure.

0-arg memo would be a core use case of memo, I figure.

But it would be a misnomer in the FP space. 0-argument memo is just lazy (for lazy init).

rbuckton: I don't know what this lazy function you're talking about is

... that's the same as T

My only concern with memoize is that it's not a true memoize unless it can take functions that accept multiple arguments and only evaluates once "for each unique sequence of arguments", and that has GC implications. It's not a blocking concern, but may be a source of confusion for anyone coming from an FP language or library that does have a true "memoize" implementation. I'm wary of borrowing something from FP but have a implementation that doesn't match the FP version.

Is the GC concern that memoized functions permanently cache their arguments?

python has lru_cache for this

rbuckton: I think you can solve the GC issues by using a tree of WeakMaps for the argument storage

I want to register, informally, that “call this” is a net negative for the precious understandability of the language. I do not think it’s useful to sweep “call” and “bind” under the syntax of the language. “call” and “apply” are perhaps warts, but they’re instructive warts.

can you elaborate on that? my belief is the opposite, that it increases understandability

thought i was free

it feels like that isn't so bad

like the case i keep thinking about is obj.method.{call,bind}(obj, val) -- this is a bit weird

my more common use cases are const method = obj.method; /* much much later */ method.call(otherObj) /* vs */ otherObj~>method()

when does one need to write this. It used to be the case with apply before spread

Rick Waldron: yes I'm sure there are entire programs that are nothing but xor, but that's not representative of the majority

but the readability harm of the status quo, that call syntax would address, is a general problem - just not a universal one

i have 2 days. shit why didn't i add this to the agenda

APL needs an EMOJI reboot.

... why do I know about VS16

fn📢method

I have been careful not to mention stuff like Node core with call-this—in the end, it’s about the fact that .call is one of the most common operations in the language (cf. the corpus analysis), and common × clunky → worth optimizing.

I could be convinced that syntax is a good solution to uncurryThis even if its usage is limited to Node.js core development.

All, if you get a mail saying Jordan has removed you as a member of TC39 Delegates on Github, fear not, you are still part of the Delegates team. Jordan is creating Github sub-teams per-member to help us track membership better. (from Rob Palmer further up)

Robin Ricard: the syntax space is already reserved though?

should i request more note takers?

there is still a difference between reserving and tolerating it

reserving means the engine will syntaxerror

Robin Ricard: yeah and again, the value of allowing it is just that you don't have to run some incredibly simple annotation stripper?

for instance, with deno, I can just throw it in the repl

Luca Casonato: can you back that up somehow?

Luca Casonato: a node REPL wrapper like ts-node can also make it just as easy to do

which is my experience of esbuild vs webpack or whatever

waldemarIf you want a specific exaple for one of your topics, `a ? (b): c => (d): e => f` is fully ambiguous (it has two possible parser results)

I have to go in 10 mins, we will need another note taker

Each person with concerns each should all try to be clear if they are blocking Stage 1.

and incentivises paying more attention to people who claim that they will block stage 1

This is reasonable. It makes me wonder what the purpose of discussion before Stage 1 ought to be, then.

it's "is this actually a problem space we want to spend more committee time on"

//: (number, number) => number would be fine

that we say : is a new comment form

Back to serious: yeah I'm 100% for being able to drop in more comment syntaxes that let us comment-annotate at a fairly tight granularity (functions, args, etc), with only the minimum amount of grammar restriction to ensure they're parseable.

any objections to me moving this forward?

jschoi: is your topic about outreach covered?

bakkot: as daniel said, the syntax has been written by an enthusiastic community member, the champions are in favor of discussing syntax

wrote up the colon thing in a little more detail: https://github.com/giltayar/proposal-types-as-comments/issues/127

Jack Works: i didn't quite understand the malicious misleading comment. surely malicious actors can do that today in many devious ways

I imagine Node.js could also have "validate types" as a runtime option and eject if types fail, again without TypeScript or Flow or whatever the next cool types tooling is.

This would require standardizing the type system itself though, wouldn't it?

the problem to be solved is "I want to write type annotations and not strip them before running code on a real engine"

Would it? Given the most basic definition in this specification, if Node.js parsed the comments and validated them, I don't know if it would. I could absolutely be wrong, though.

I guess it depends on what "validate" means. Does validate == type check?

"eject on mismatch between reality and type comment" is what I mean and also could probably be defined as type checking

Ok, I don't think that would be possible with the current scope of the proposal.

also I'd like to understand WHY they want to write the types inline, if they have no effect, and they're not fully compatible with TypeScript types

Robin Ricard: many delegates have said that they would oppose adding he full typescript syntax here, so that is not a covered use case

I am people

Robin Ricard: we would probably only be willing to carve out a narrow (but infinite) syntax space for them, like what bakkot suggested, and they will need to adapt

can't we conclude that the remainder of the TS features are aimed at "power users" and thus behind the compile wall?

there are two parts: 1) ergonomic types as comments that run in the browser 2) consolidating popular js forks is a problem, and ts is very popular

there are two parts: 1) ergonomic types as comments that run in the browser 2) consolidating popular js forks is a problem, and ts is very popular

does that sound more like a problem statement?

so are those of us that like dynamic/weak typing going to be dragged kicking and screaming into the world of strong typing? asking for a friend

// tool-disable-checking-next-line is your new best friend! :D

"actual comments" would work fine for those purposes too tho

SoftwareChris: I think the fact that this proposal isn't actually trying to add real typing shows that's not the case?

and at that point, why not also have non-comment syntax forms

since it's always, only, been type annotations

Flow also has enums :)

SoftwareChris: why would anything in this proposal impact someone who wanted to write plain JS?

does this mean actual types?

I don't know what "actual types" means. what I'm saying that if you're already committed to not being legal JS (because you have enum and whatever), it makes a lot more sense to also add other new syntax, as typescript has done

SoftwareChris right, but the standard doesn't actually prevent you from writing code not in the standard. Are you worried that companies and teams will decide to adopt it, and so it might be difficult to find a codebase to work in regularly that does not use these comments?

JSDoc has been around for decades, but it never got mainstream adoption, never got phenomenal IDE support, never was expanded upon

JSDoc didn't have an actual working type system to use with it

so, I would actually have gone for a different problem statement, which is, "the current syntax forms for comments are unergonomic to use as inline annotations, which has lead to forks of the language"

but "taken over by types" and "taken over by comments that are types" seems the same to me

danielrosenwasser: are you available at the end of day 4 (thursday)?

in terms of innovation, a question that was asked during plenary. It feels liberating if bundlers and minifiers could forget about keeping up to date with supporting different type syntaxes, and instead use that effort for their primary use-case

Jack Works: my only point was that you said something like "we should try to add those transpilers in the devtools" and i just wanted to respond that we can only have that be a request, not a requirement

bundlers in particular would benefit, but many tools, like prettier, would actually need to parse the types themselves, and so would still rely on the more specific grammar which TS or flow or whatever actually used

people want to replace type x = { a: number, b: number } with type x = { a: number; b: number }, e.g.

adding it to the language is request every engine to implement it, I think they're the same thing

i feel like we're talking past eachother here a bit. are you suggesting that we consider the TypeScript transpiler "standardized"? or are you just suggesting that we add developer tooling support for the types as comments proposal that was presented earlier today?

if the core need of the proposal is to run code without transpile, devtools built-in ts & flow transpile can help people so we don't have to add that in the core language 👀

Having made a variety of contributions to Prettier, I do not see at all how it would be possible to have some kind of "progressive enhancement" or "graceful degradation" - we would be talking about creating a whole new tool

sure, but TS/Flow/etc. is not standardized, so we as a standards body cannot require that developer tooling (which are all also not standardized) add support

Having made a variety of contributions to Prettier, I do not see at all how it would be possible to have some kind of "progressive enhancement" or "graceful degradation" - we would be talking about creating a whole new tool