IMPLEMENT GET SET similar c# "NOT DUPLICATE"

[srburton]

class Car{

public name {get; set; }
public marca {get; set;}

}

var c = new Car();

c.name = "fusca"; //SET

console.log(c.name); //GET

In case the compiler only needs to remove the
{get; set;} and set a common variable what do they think?

[DanielRosenwasser]

Hey, thanks for filing, but this seems to be a duplicate of #10911

In the future using the issue tracker's search functionality can make it easier for us to triage issues. Thanks!

[srburton]

That applies to decorators who yes is a useless implementation does not make sense even by how decorator the expression is simple

"public name {get; set;}"

example is decorators

"@get public name"

[RyanCavanaugh]

#7628

[srburton]

Where in the typescrypt compiler is the class counter in the typescrypt core so I can commit it and you see it's simple

#typescrypt.

class Car {
   
   public name {get; set;}

}

javascript example

var Car = function (...) {

     Car.prototype.name = null;

}

[srburton]

public name {get; set;} not is function !!!

default ->>
get : any
set: any

[srburton]

or

public name {get:string;set:any}

[kenlacoste843]

already discussed in #7628 mate..

One reason for this design tenet is that TS wants to stay compatible with future JS standards.

What if in the future JS chooses a different syntax for simplified properties? This happened in the past with modules and it was a little messy to recover from. Worse: what if JS introduces a new syntax that is plain incompatible with your proposed syntax?!

As kitsonk said, you probably should raise your voice at TC39 first so that the idea can trickle down from JS to TS.

the nearest that even got votes from the contributors is this #2763 where it considered its translation, compatibility and benefit towards .JS.

[srburton]

I'm just sorry

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.