Jeongho Nam

I think it would better to change your type. Your case seems too domestic and occurs hard coding.

```typescript type MyNumber = number & { __brand__?: Something; } ``` If not like above, then no way to validate. In actually, below type becomes compile error in `tsc`. No...

Then make the brand type's property to be optional. `typia` cannot support that TypeScript compiler occurs error case.

 If TypeScript core team makes it not be compile error, I'll consider your opinion. As you know, `typia` is using the pure Typescript type directly, so no way to...

How long do we have to repeat the same story? This is runtime validator libary, so that no way to distinguish the brand type. If `string & object` type comes,...

No matter how much you claim that "this is reasonable", in reality it is not. The Brand type is contradictory and is an area that validators cannot support. When considering...

If you still want the brand type, how about determining a policy for the priorities between each element that composing the intersection type, especially about the nonsensible case. Note that,...

## `equalStringify()` `typia.json.stringify()` and similar functions `typia.json.assertStringify()` still do not serialize superfluous properties. Therefore, your purpose is already accomplished. ## `equalParse()` You can accomplish it by combining `typia.json.assertParse()` and `typia.misc.prune()`...

Oops, just hope to revive the namespace. Too much change for me.

> Oh you implemented for LLM? thank you Not yet but soon. It's the reason of 2 weeks later's v6.10 publlishing.