ObjectLiteralType - Assignment Operator Fails, property type missmatch. Similarly cast fails

[wesleyolis]

The inferred types for object literals were their properties for "string literal" is string and not object literal string value, is in consistent with explicit typing. Object Literals properties inferred type are of weaker constraint than the explicit type declaration, they should be identical. This also occurs with literal numbers.

type CastObjectLiteral = {a :'stringLiteral' }

const value = {a : 'stringLiteral'}

let assignable : CastObjectLiteral;

assignable = value; // This doesn't even work in the @next versions.
/*
error TS2322: Type '{ a: string; }' is not assignable to type 'CastObjectLiteral'.
  Types of property 'a' are incompatible.
    Type 'string' is not assignable to type '"stringLiteral"'.
*/


notCallable(value)  // doesn't work in latest @next versions
/*
test.ts:20:13 - error TS2345: Argument of type '{ a: string; }' is not assignable to parameter of type 'CastObjectLiteral'.
*/

notCallable(value as CastObjectLiteral); // Works in @next, but doesn't work in 2.6.2

assignable = value as CastObjectLiteral;    // Work in @next
assignable = <CastObjectLiteral>value;     // Work in @next

function notCallable(notassigble : CastObjectLiteral) : void
{

}

[RyanCavanaugh]

Please use the issue template, even if this isn't your first bug. It's very helpful for us.

This is the intended behavior because value.a is still mutable. The OP doesn't provide a definition for notCallable so I'm not sure what the intent of it is.

[wesleyolis]

I shall in future confirm to the requested of bug logging format.

I see what you are saying, is that members, keys of a const object is still mutable, therefore the inferred type will not be a literal version of the type, which is by the current design which makes sense.

The problem for me is that I would expect to have a way to ensure that typeof operator on a const object keys and member types remain const and not mutable, so I could match an explicit type definition.

Is their anyway currently in which to perform the const object assignment(setup), which would result in the typing system having the same type constraints as an explicit type.
Because I ran into this problem in a more complex set of things, but all boils down to this mutable fact.

Is their anyway to do anything along the lines of this?

type ReadonlyNumber<N extends number> = (readonly|const) N
readonly const value = {a : 3434 as ReadonlyNumber<3434>}

readonly const value = {a : 3434 as readonly number}

function literalTypeExtraction<T>(value : T) : T{
 return value;
}

readonly const value2 = {a : literalTypeExtraction(345)} // also results in a:number.

I feel I may have just confused this with this problem in a way, the behaviour I was describing here, were the root cause of this problem is that it is that members are still mutable.
Here

[RyanCavanaugh]

@wesleyolis see #10195