[go: nahoru, domu]

Skip to content
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

[RFC] Towards Non-Fungible Types #48513

Closed
DanielRosenwasser opened this issue Apr 1, 2022 · 27 comments
Closed

[RFC] Towards Non-Fungible Types #48513

DanielRosenwasser opened this issue Apr 1, 2022 · 27 comments
Labels
Community Tooling This might be better handled by tooling from the community instead of built into TypeScript In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@DanielRosenwasser
Copy link
Member
DanielRosenwasser commented Apr 1, 2022

For years TypeScript has strived to grow and support its community. We've seen some tremendous investment, innovation, creativity, and beauty from TypeScript developers.

export type ConsistentWith<DecorationTargetProps, InjectedProps> = {
  [P in keyof DecorationTargetProps]: P extends keyof InjectedProps
    ? InjectedProps[P] extends DecorationTargetProps[P]
      ? DecorationTargetProps[P]
      : InjectedProps[P]
    : DecorationTargetProps[P];
};

export type PropInjector<InjectedProps, AdditionalProps = {}> = <
  C extends React.JSXElementConstructor<ConsistentWith<React.ComponentProps<C>, InjectedProps>>,
>(
  component: C,
) => React.JSXElementConstructor<
  DistributiveOmit<JSX.LibraryManagedAttributes<C, React.ComponentProps<C>>, keyof InjectedProps> &
    AdditionalProps
>;

But how will we ensure that creators of these innovative types are rewarded for their brilliance? How do we make sure people continue writing more beautiful types?

This question coincides with the advent of "WEB 3", a broader community shift which can be best explained by aggressively waving one's hands. Many fascinating ideas have come from the "WEB 3" world including NFTs - Non-Fungible Tokens, which are simply Tokens which caNnot be Funged.

This dovetails with another new concept which I would like to introduce today: Non-Fungible Types.

The Idea

Today we see the broader use of non-fungible tokens for breathtaking pictures of apes that look like they've just been laid off - the biggest explosion of art collection since pogs, Beanie Babies, Pokémon cards, and fidget spinners.

What a lot of people don't realize is that TypeScript code is art.

How do we figure?

Well, if you've ever heard the expression "ars longa, vita brevis" – Latin for "art is long, life is short" – then you almost immediately recalled a TypeScript type you saw in an error message. It really does seem obvious when you put it that way!

In fact, you have a wide variety, ranging from minimalist TypeScript art...

type a = {}

to surreal TypeScript art...

type UnionToIntersection<T> = 
  (T extends any ? (x: T) => any : never) extends 
  (x: infer R) => any ? R : never

So TypeScript types are great candidates for NFTs! Users should be able to take NFTs of type declarations and annotations and build a thriving ecosystem of type system artisans.

Do individual types actually have value?

I've discussed this proposal with my math friends from college experts in the field who have kinda offhandedly postulated over chat apps assured me that thanks to Cantor's Diagonal Argument, there are an uncountably infinite number of types. So can we really induce shortage to ensure value for every type?

Well growing up, I argued with my cantor all the time so I remain undeterred.

Thanks to the unfungibility of the types, the value comes from the convenience of the types! So imagine that you're writing a program that uses types like string, number, boolean, null, or undefined. As an upstanding citizen of the non-fungible-type community, you would need to get permission from the NFT owner(s) of these types. You could consult a chain of blocked accounts on Twitter to figure out who must own it, DM them, and ask them for permission to use these types, at which point they might charge a reasonable fee.

Imagine not just appropriately compensating this artist, but also the sort of community building that this will enable!

Won't this mean I can't write programs for free?

Like we mentioned, there's plenty of types to go around! Want to say you take a string without paying to use string?

Just use a structurally compatible type with an optional member of type never

type MyString = {
    toLowerCase(): MyString;
    toUpperCase(): MyString;
    slice(start?: number, end?: number): MyString;

    // ...

    myUselessMember134020105168421?: never;
}

See? It's still free! Freedom is a state of mind!

What about primitives like string, number, and boolean? Who owns those?

Currently I have the non-fungible-tokens for string, number, boolean, bigint, null, and undefined. I also have {} and the non-primitive type object. As an early pioneer in this ground-breaking space, it only feels fair to lay an early claim to these.

Someone else can use symbol. It's whatever.

Who owns never and unknown?

I am gladly donating never and unknown to @ahejlsberg so that I never have to explain them again.

Who owns any?

Technically someone on the core team does, but they seem to have lost access to their credentials and we don't want to tell you all who it was.

We recommend not using any until we can figure out how to access it again.

Timeline

I would like to see this happen soon. The fact that we have only created this proposal as recent as April 1st, 2022 means that we are already at risk of falling behind. Now is the best time to act!

@DanielRosenwasser DanielRosenwasser added Suggestion An idea for TypeScript In Discussion Not yet reached consensus Community Tooling This might be better handled by tooling from the community instead of built into TypeScript labels Apr 1, 2022
@craftytrickster
Copy link

Are these types open to manipulation like normal "fiat" JS types? For example, what would happen if I instantiated an object, and then some unscrupulous third party "manipulated" its .prototype field to point to a different class' prototype? Would I still be able to brag to my friends about my special NFT type and post selfies on social media, or would I simply be holding what amounts to be a very fancy pointer?

@nicolo-ribaudo
Copy link

There might be an uncountable number of types, but we can only define a countable quantity of them. They are still a lot, but this is a big step towards scarcity.

@xiBread
Copy link
xiBread commented Apr 1, 2022

I would like to buy symbol. Do you accept payment in pennies?

@DanielRosenwasser
Copy link
Member Author

Are these types open to manipulation like normal "fiat" JS types? For example, what would happen if I instantiated an object, and then some unscrupulous third party "manipulated" its .prototype field to point to a different class' prototype? Would I still be able to brag to my friends about my special NFT type and post selfies on social media, or would I simply be holding what amounts to be a very fancy pointer?

I'm not sure, I hadn't put a lot of thought into what @craftytrickster‍s like you might do with these.

@gabritto
Copy link
Member
gabritto commented Apr 1, 2022

What if a right-clicker just copies and pastes my types? 😕

@louwers
Copy link
louwers commented Apr 1, 2022

To make things more economically viable, owners of type A should get a comission when someone mints a type that is assignable toA. With that said I would like to claim interface { toString(): string }.

@johnnyreilly
Copy link

Can we start calling type artists "tartists"? Who wouldn't want to be a tartist? 😉

@connor4312
Copy link
Member

Has the environmental impact of this proposal been considered? I've heard "proof of steak" is better for that, should we leave steaks on TS team members' desks with a note of which type we wish to claim?

@fatcerberus
Copy link

It should be noted that in order for types to be truly non-fungible, we first need to switch to nominal typing. Otherwise class A {} and class B {} are fungible!

@johnnyreilly
Copy link

should we leave steaks on TS team members' desks

There's prior art here courtesy of @JoshuaKGoldberg: #29374 (comment)

Essentially, leave cakes not steaks. 🎂

@simeyla
Copy link
simeyla commented Apr 1, 2022

I've been waiting for this announcement:

export type OptionalCat = { cat?: string, name: string };
export type DefiniteCat = { cat: string, name: string };
export type OptionalDog = { dog?: string, name: string };
export type DefiniteDog = { dog: string, name: string };

Up until now I was only able to assume nobody else had ever stolen these types.

@CyrusNajmabadi
Copy link
Contributor

Similar concept being considered over at csharplang: dotnet/csharplang#5976

@Fireboltofdeath
Copy link

I like this idea but how will this be enforced? I think if we use a trust model then the right clickers will just use our types without permission. Would it be feasible to connect TypeScript to the blockchain to verify that you can actually use the types you're attempting to? I think this would go a long way to protect the copyright of all tartists.

@DanielRosenwasser
Copy link
Member Author

A lot of you have raised the risk of right-clickers copying precious types.

I will reach out to partners on our editor teams to see if we can fix this. I think if Visual Studio and Visual Studio Code lead the pack, we may be able to disable right-clicking in TypeScript files in all editors!

Admittedly, I'm not that well-connected. To start small, does anyone have the phone number for the CEO of the nano editor corporation?

@xiBread
Copy link
xiBread commented Apr 1, 2022

Admittedly, I'm not that well-connected. To start small, does anyone have the phone number for the CEO of the nano editor corporation?

You might have luck with 248-434-5508.

@MartinJohns
Copy link
Contributor

does anyone have the phone number for the CEO of the nano editor corporation?

Try 0118 999 881 999 119 7253.

@DanielRosenwasser
Copy link
Member Author
DanielRosenwasser commented Apr 1, 2022

@MartinJohns I think now that you mention it, I've seen this number for their hotline. It's a long one, but luckily they have a catchy jingle!

@hasparus
Copy link
hasparus commented Apr 1, 2022

I have a concern about typeconomics.

Wouldn’t it help the adoption to pay tartists per error than per use? (based on error length ofc)
I’m a huge fan of this endeavor, and I’d like to ensure we are truly going to the moon 🚀🌙

On another note, when is the Non-Fungible-Type Marketplace plugin coming to TS Playground?

@jcalz
Copy link
Contributor
jcalz commented Apr 1, 2022

And to think, up until now I've just been busking UnionToIntersection definitions in subways and public parks for spare change!

@goodcodedev
Copy link

What if a right-clicker just copies and pastes my types? confused

Let's doubleclick it.

@mindplay-dk
Copy link

I'd like to make a bid for Window and Document - I have a feeling these are going to see some use in the future.

@SalvatorePreviti
Copy link
SalvatorePreviti commented Apr 3, 2022

To ensure artificial scarcity to keep the Non Fungible Types values high, we could introduce a form of proof of work - I would propose that the typescript compiler will support mining types, for registering a type TSC will first try to find a 32 bit nonce that would satisfy sha256(sha256(source of the type without spaces + nonce)). Integrating WebGPU in TypeScript could be helpful to do it in a reasonable amount of time and seems fair that a developer has to have a powerful GPU to compile typescript code. A new command line argument "tsc --nft file.ts" would be handy to have an interactive NFT registration experience.

@fatcerberus
Copy link
interface Monke {
    get ugliness(): number;
    eat(what: Banana): void;
    beHappy(): never;
}

original type do not steal

@MartinJohns
Copy link
Contributor
MartinJohns commented Apr 3, 2022

I'm starting to suspect this was an April Fools' joke and not the future of TypeScript. Perhaps you meant to add the tag Community Fooling instead of Community Tooling?

@tjjfvi
Copy link
Contributor
tjjfvi commented Apr 3, 2022

@fatcerberus I made my own Monke type, too!

interface Monke {
    get ugliness(): number;
    eat(banana: Banana): void;
    beHappy(): never;
}

plz no steel

@RyanCavanaugh
Copy link
Member

Thanks for the feedback everyone! I see a bright future for the --noImplicitFunging flag.

We are looking into revoking Daniel's issue-filing permissions.

@SlurpTheo
Copy link

Someone else can use symbol. It's whatever.

I am gladly donating never and unknown to @ahejlsberg so that I never have to explain them again.

🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Community Tooling This might be better handled by tooling from the community instead of built into TypeScript In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests