fsharp / fsharp/fslang-suggestions

Strict type aliases

Open
#1,098 14 comments 21 reactions 0 assignees View on GitHub
area: type-system
Dominant language
No language data
Stars
373
Forks
21
PR merge metrics
No merged PRs in 30d

Description

Often when modeling domain cleanly or trying to refactor some legacy code, I (and my friends / collegues) use type aliases to bring more "context" to function/type w.e. signature

The problem is that compiler still doesn't help with reducing mistakes this way: eg programmer is actually on his own. Aliased type still can be interchanged when consumed: eg.

``` fsharp
type UserName = string
type UserLogin = string

let consumeUserName (userName: UserName) = ...
let userLogin: UserLogin = "myLogin"

consumeUserName userLogin ... // <- valid code, compiler cannot really help

```

Compiler already has a great way to help in similar case: Units of Measure, eg. `int` cannot be mistaken with `int` from compiler's point of view.

I'm proposing an Attribute which will tell compiler to see those types as something like base type + hidden unit of measure.
Something like:

``` fsharp
type UserName = [] string
type UserLogin = [] string

let consumeUserName (userName: UserName) = ...
let userLogin: UserLogin = "myLogin"

consumeUserName userLogin ... // <- invalid code

let myName: UserName = userLogin // something like an "explicit cast", manually tell compiler to see this value as UserName instead of UserLogin

consumeUserName myName... // <- valid code now
```

I think casting syntax isn't ideal here. But it still solves my problem at least. It needs to be given much more thought, to make it explicit but at the same time not too boilerplaitish I guess.

The existing way of approaching this problem in F# is well, be careful about it.
Also, there is UMX, but it doesn't cover all cases and I do not think that units of measure are really great fit here. They were designed for a different thing after all.
Some people use Single case DU for this but I think they still have this boilerplate problem. Also, forgetting to put `[]` attribute can potentially lead to huge increase in allocations.

## Pros and Cons

The advantages of making this adjustment to F# are ...

I think the main advantage is type safety. Reducing the chance of using invalid type.

The disadvantages of making this adjustment to F# are ...

Not like disadvantages but more like what this proposal is not trying to solve:
This doesn't make the code any safer to outside consumers eg. C#
People still have to remember that this is just an alias, strict or not, e.g. registering an aliased type in DI will result in registering base type etc.

## Extra information

Estimated cost (XS, S, M, L, XL, XXL):

I think it's something around M, as compiler already has infrastructure for this feature.

## Affidavit (please submit!)

Please tick this by placing a cross in the box:
* [x] This is not a question (e.g. like one you might ask on [stackoverflow](http://stackoverflow.com)) and I have searched stackoverflow for discussions of this issue
* [x] I have [searched both open and closed suggestions on this site](http://github.com/fsharp/fslang-suggestions/issues) and believe this is not a duplicate
* [x] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:
* [x] This is not a breaking change to the F# language design
* [ ] I or my company would be willing to help implement and/or test this

## For Readers

If you would like to see this issue implemented, please click the :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the proposed StrictAlias examples and the issue's discussion of Units of Measure, UMX, and single-case discriminated unions. No repository files or tests are named; done would require an agreed language design followed by compiler implementation and validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
compilers
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.