Proposal: type aliases in Clarity

[lgalabru]

In the context of the BNS contract, I'm dealing with the following type:

(price-function (tuple 
    (buckets (list 16 uint)) 
    (base uint) 
    (coeff uint) 
    (nonalpha-discount uint) 
    (no-vowel-discount uint)))

It could be nice, from a developer point of view, to have the ability to define type aliases, aiming at improving readability:

(define-type price-function-type (tuple (buckets (list 16 uint))
                                         (base uint)
                                         (coeff uint)
                                         (nonalpha-discount uint)
                                         (no-vowel-discount uint)))

It could be an edge case not worthing the effort - opening an issue for tracking this idea.

[njordhov]

Custom types would be interesting. Also, perhaps we could have a generalized type test function like say (is ...) for custom types and in place of is-none, is-ok and the proposed is-err and is-some.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lgalabru]

Would be addressed if the define-macro solution described in #1638 is adopted

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[friedger]

Writing the same types in function parameters is long and tedious

[MarvinJanssen]

From the discussion: if implemented, these type definitions/aliases would be local to the current contract only.

Edit:

And an example where it would help:
https://github.com/MarvinJanssen/clarity-experiments/blob/95b5a77aed24fb401f7ce8b09c5e1d7772df953d/contracts/tiny-market.clar

(define-type listing
	{
		maker: principal,
		taker: (optional principal),
		token-id: uint,
		nft-asset-contract: principal,
		expiry: uint,
		price: uint,
		payment-asset-contract: (optional principal)
	}
)

(define-map listings {id: uint} listing)

(define-private (assert-can-fulfill (nft-asset-contract principal) (payment-asset-contract (optional principal)) (listing listing))
	(begin
		(asserts! (not (is-eq (get maker listing) tx-sender)) err-maker-taker-equal)
		(asserts! (match (get taker listing) intended-taker (is-eq intended-taker tx-sender) true) err-unintended-taker)
		(asserts! (< block-height (get expiry listing)) err-listing-expired)
		(asserts! (is-eq (get nft-asset-contract listing) nft-asset-contract) err-nft-asset-mismatch)
		(asserts! (is-eq (get payment-asset-contract listing) payment-asset-contract) err-payment-asset-mismatch)
		(ok true)
	)
)

[njordhov]

ClarityTools brings type aliases to Clarity, generating the polyfill. Check it out:

https://shrtco.de/gYMidi

Use Generate Clarity from the Toolbox menu for the canonical code.

[MarvinJanssen]

Edit: I just saw the label changes by @jcnelson. I'll keep the post though.

I'd like to bump this. Has any determination been made on whether or not to include such a feature?

I think it could be a fantastic additional also for standardisation of types. Now that it seems that SIP018 is coming to Stacks we will see more custom tuple times be part of a larger protocol.

Next to a define-type, I also want to suggest a use-type that works just like use-trait but for types. The signature can look like this:

(use-type type-alias type-identifier)

Which would allow us to do something like this:
contract-a.clar:

(define-type order {maker: principal, amount: uint, salt: uint})

contract-b.clar:

(use-type defi-order 'SP123.contract-a.order)

(define-public (some-func (order defi-order))
;; ...
)

Thoughts?

[jcnelson]

Assigning to @obycode for now. Please re-assign as appropriate.

[obycode]

I like this idea too. I'm going to open an issue in the SIPs repo to track the proposal, then leave this one here for the implementation.