Improper usage of properties with missing set / get should be an error

[basarat]

If a property has a getter but no setter (or vice versa) than perhaps the attempt to set or get should be flagged as an error:

class Fields{
 get ReadOnly(){
 return 10;
 }

 public written:number;
 set WriteOnly(value:number){
 this.written = value; 
 }
}

var obj = new Fields();

console.log(obj.ReadOnly); // 10
obj.ReadOnly = 20; // cannot set but no error 
console.log(obj.ReadOnly) // 10 

obj.WriteOnly = 20; 
console.log(obj.written) // 20 
console.log(obj.WriteOnly); // cannot read but no error 

No biggie. But something to be aware of. (ported from http://typescript.codeplex.com/workitem/834)

[danquirk]

It certainly would be nice. The biggest problem here is that getter/setter and properties are not differentiated at the type level. That is, the .d.ts for the above type is:

class Fields {
 ReadOnly: number;
 written: number;
 WriteOnly: number;
}

so obviously you now can't do any of these kinds of checks unless you have the full implementation to inspect. If we did #12 then this kind of checking would likely fall out of that nicely so I'm just going to close this.

[myitcv]

Dan Quirk (@danquirk) looking at the issues that are linked to #12, it seems the vast majority relate to this issue, namely the silent treatment of accessing non-existent getters/setters.

Is there something preventing getters/setters being differentiated at the type level?

[joelday]

Dan Quirk (@danquirk) This needs to be deduped from #12. This is about a compile time error for a guaranteed run time failure.

[KoenT-X]

I just ran into this very same bug. If there is no setter for a property, then an error should be flagged (or at least a warning).

[AGiorgetti]

Yep, I still hit this error times and times again (especially in TypeScript code written by people that start using the language right away without looking into it deeply).

" it compiles, so it should just work" this is what they say...