No error when attempting to read a write-only property

[battmanz]

TypeScript Version: 2.0.3

Code

// This works as expected
class Demo1 {
  get foo() {
    return 'hi';
  }
}

let d1 = new Demo1();
d1.foo = 'wat'; // An error is given (as it should be) because foo is read-only.

// This does NOT work as expected
class Demo2 {
  private _foo: string;

  set foo(foo: string) {
    this._foo = foo;
  }
}

let d2 = new Demo2();
console.log(d2.foo); // No error, but there should be because foo is write-only.

Expected behavior:
A compiler error should be given when attempting to read a write-only property.

Actual behavior:
There is no compiler error.

[mhegazy]

This is working as intended. a write only property is not very useful, and is not something that is supported in the type system. the two supported variations are readonly, and read-write.

[battmanz]

I agree that write-only properties aren't used very often, but just to be consistent/complete, I would think that if the language supports readonly properties then it would support write-only properties as well. In C#, for example, I would get an error if I tried to read a property that only had a setter.

If the language truly does not support write-only properties, as you say, then please give a compile time error if I try to do so. So to update my earlier example:

class Demo2 {
  private _foo: string;

  set foo(foo: string) { // error: write-only properties are not allowed
    this._foo = foo;
  }
}

[mhegazy]

JS allows getter-only and setter-only properties. so at runtime this code would work. the write would invoke the setter, the read would always return undefined. The type system does not model it. there is read/write, and read-only but no write-only.

I see the proposal of making it an error. it just does not happen that often, but we can discuss it.

[aluanhaddad]

I don't think it should be an error to define a property with only a set attribute. It might be nice if it was an error to use such a property in an rvalue context. I'm guessing that this would make assignability analysis much more complicated for little benefit.

[dungdm93]

I think TypeScript should cover more cases as:

interface Foo {
    foo: string;    // abstract property = getter + setter
}

// No compile error, but there should be because no foo's setter implemented.
class Bar implements Foo {
    private bar: string = "Batman";
    get foo(): string {
        return this.bar;
    }
}

// No compile error, but there should be because no foo's getter implemented.
class Baz implements Foo {
    private baz: string = "Superman";
    set foo(value: string) {
        this.baz = value;
    }
}

// No compile error, but there should be because Quiz.foo not match Foo.foo signature
class Quiz implements Foo {
    readonly foo: string = "Iron man";
}

// This is OK.
class Fine implements Foo {
    private fine: string = "Captain America";
    set foo(value: string) {
        this.fine = value;
    }
    get foo(): string {
        return this.fine;
    }
}

and even this

abstract class A {
     abstract get name(): string;
}

// No error at all. :((((((
class C extends A {
    foo: string;
    set name(value: string) {
        this.foo = name;
    }
}