Omit private symbols from type about typescript HOT 6 CLOSED

It mimics private properties the way it is now, by preventing you from assigning external stuff to it. If you do class Foo {private a = 0} then you cannot write const x: Foo = {} without error. Private properties aren't completely invisible, they're just inaccessible. It seems to me that anyone using code of the form used in your example might well want it to behave just as it does now (except for maybe the declaration error) and keep track of the inaccessible property. What, specifically, is wrong with having to annotate the type to be what you want?

from typescript.

Sorry, but I don't understand why would anyone want to keep track of the inaccessible property? Also, type annotations are fine, I just like to keep things concise. With explicit annotations you have to write an interface first and then repeat it in implementation. Otherwise, you can just write an implementation and use inferred type as a contract. Seems better to me, but maybe I am wrong.

I see this suggestion as syntactic sugar, kinda like this ... constructor(private name: string) { } ... or other shortcuts.

from typescript.

The following code is using JS private properties and demonstrates exactly why inaccessible but visible is important. This is how JS works, it's how TS's private works, and it's how things currently work with symbols.

class Foo {
  name;
  #val;
  constructor(name: string, val: string) {
    this.name = name;
    this.#val = val;
  }
  compareOther(other: Foo) {
    return this.#val.toUpperCase() === other.#val.toUpperCase();
  }
}

const foo1 = new Foo("foo1", "foo");
const foo2 = new Foo("foo2", "Foo");
foo1.compareOther(foo2);

const notAFoo = { name: "notAFoo", compareOther(other: Foo) { return false } };
foo1.compareOther(notAFoo); // error

from typescript.

Oh, I see. So I guess explicit type annotation is the only way in my case? I made a small recursive Omit helper to automatically filter out private parts of my code. Not sure if it's the good choice, but it seems to be working.

type RecursiveOmit<T, O> = {
    [P in keyof T as P extends O ? never : P]: 
        T[P] extends Array<infer U> // also check other built-in types (Set, Map, etc.)
            ? RecursiveOmit<U, O>[]
            : T[P] extends object
                ? RecursiveOmit<T[P], O>
                : T[P]
}

const _ = Symbol()

export function createSomething() {

    function createItem() {
        return {
            name: 'item',
            [_]: {
                implementationDetails: ''
            }
        }
    }

    const self = {
        items: Array<ReturnType<typeof createItem>>(),

        someMethod() {
            this.items[0][_].implementationDetails
        }
    } 

    return self as RecursiveOmit<typeof self, typeof _>
}

// {
//     name: string;
// }
type Item = ReturnType<typeof createSomething>['items'][0]

function handleItem(x: Item) {}

handleItem({name: 'test'}) // No error anymore

from typescript.

The proposed behavior seems really buggy if you don't expect it, especially if you consider the case of type operations occurring within the context of createSomething where you might be tracking necessary internal state.

from typescript.

Yeah, turned out it wasn't well thought.

from typescript.