Hasitha Aravinda

Can't we use `@display` annotation here, with additional meta data? Each stdlib module has to follow the same convention.

@indikasampath2000 But the record is open, you can have additional metadata called, kind/type, etc.. e.g.: ```ballerina type SomeConfig record { string username; @display { label: "auth token", kind: "password" }...

@hevayo +1 to reserve those as optional fields. IMO, we only need one attribute for both cases, and its values should be a subset of HTML input types. @hevayo, Since...

In HTML input type `file` means, file upload. But in our case, what we need is file-path, which is mapped to `url` in HTML input types.

I think it is UI Form generation's decision to how to render string or record filed. What we can do is we can put `@display { kind : "password" }`...

Yes, I agree with @MaryamZi comment. IMO We can omit the term `dependently-type` and simply say the function's name.

There are different variations when it comes to escaping and unescaping, We can't expose all these variations as part of the syntax or semantic API. We have this `identifier-util` which...

Let's temporarily close this PR, until we finalize the design.

@MaryamZi @prakanth97 I think, we should disable allowing the call-expr on the union of function types, even with the union has the same shape. This has multiple edge cases, so...

@prakanth97 there are conflicts.