dsainati1 Github contribution chart
dsainati1 Github Stats
dsainati1 Most Used Languages

Activity

29 Sep 2022

Issue Comment

Dsainati1

Extensibility flip

Adds FLIP proposing adding Extensions to Cadence. See discussion in https://forum.onflow.org/t/extensibility/622 and https://github.com/onflow/cadence/issues/357


For contributor use:

  • [X] Targeted PR against master branch
  • [X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • [X] Updated relevant documentation
  • [X] Re-reviewed Files changed in the Github PR explorer
  • [X] Added appropriate labels

Forked On 29 Sep 2022 at 05:34:31

Dsainati1

https://github.com/onflow/flips/pull/11 is a new FLIP proposing an alternative to this one: attachments, which are designed to solve the same problem in a more dynamic fashion, with less static typing. It has strengths and weaknesses of its own, and I am hoping we can compare and contrast these to better evaluate both of them.

Commented On 29 Sep 2022 at 05:34:31
Pull Request

Dsainati1

FLIP for Attachments

Created On 29 Sep 2022 at 05:32:22

Dsainati1

publishing event includes recipient address

Pushed On 29 Sep 2022 at 05:30:00
Create Branch
Dsainati1 In onflow/flips Create Branchattachments-flip

Dsainati1

Flow Improvement Proposals

On 29 Sep 2022 at 05:29:29

Dsainati1

Update runtime/account_test.go

Pushed On 29 Sep 2022 at 04:02:30
Merge

Dsainati1

Publish and Claim: Inbox API for Capability Bootstrapping

Closes #https://github.com/onflow/cadence/issues/1951

This is an implementation of the Publish/Claim API described in this FLIP: https://github.com/onflow/flow/pull/1122


  • [X] Targeted PR against master branch
  • [X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [X] Code follows the standards mentioned here
  • [ ] Updated relevant documentation
  • [X] Re-reviewed Files changed in the Github PR explorer
  • [X] Added appropriate labels

Forked On 29 Sep 2022 at 04:01:00

Dsainati1

```suggestion // Check key1 ```
On 29 Sep 2022 at 04:01:00

Dsainati1

Publish and Claim: Inbox API for Capability Bootstrapping

Closes #https://github.com/onflow/cadence/issues/1951

This is an implementation of the Publish/Claim API described in this FLIP: https://github.com/onflow/flow/pull/1122


  • [X] Targeted PR against master branch
  • [X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [X] Code follows the standards mentioned here
  • [ ] Updated relevant documentation
  • [X] Re-reviewed Files changed in the Github PR explorer
  • [X] Added appropriate labels

Merged On 29 Sep 2022 at 04:02:23

Dsainati1

Commented On 29 Sep 2022 at 04:02:23

Dsainati1

Publish and Claim: Inbox API for Capability Bootstrapping

Closes #https://github.com/onflow/cadence/issues/1951

This is an implementation of the Publish/Claim API described in this FLIP: https://github.com/onflow/flow/pull/1122


  • [X] Targeted PR against master branch
  • [X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [X] Code follows the standards mentioned here
  • [ ] Updated relevant documentation
  • [X] Re-reviewed Files changed in the Github PR explorer
  • [X] Added appropriate labels

Merged On 29 Sep 2022 at 04:02:23

Dsainati1

Commented On 29 Sep 2022 at 04:02:23

Dsainati1

add language clarifying the type parameter's type in the private and public path iteration functions

Pushed On 28 Sep 2022 at 10:49:38

Dsainati1

Merge pull request #2012 from onflow/sainati/2011-iteration-docs

Add language clarifying the type parameter's type in the private and public path iteration functions

Pushed On 28 Sep 2022 at 10:49:38

Dsainati1

Add language clarifying the type parameter's type in the private and public path iteration functions

Created On 28 Sep 2022 at 10:49:38

Dsainati1

Take argument labels into account when declaring members for nested declarations

Re-port of #1717 to Stable Cadence. It had been previously accidentally reverted by merging master into the Stable Cadence feature branch.


  • [ ] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 28 Sep 2022 at 08:50:29

Dsainati1

Commented On 28 Sep 2022 at 08:50:29

Dsainati1

Improve parser function naming, remove dead code

Description

While resolving conflicts in #2014 I realized the naming can be improved and dead code can be removed. The must prefix is commonly used for functions that panic on failure.


  • [x] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 28 Sep 2022 at 07:05:39

Dsainati1

Commented On 28 Sep 2022 at 07:05:39

Dsainati1

Make argument names in test-stdlib compatible with stable cadence

Description

Keywords are not allowed to be used as variable names in Stable cadence. So changing the argument transaction to tx.


  • [x] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 28 Sep 2022 at 07:05:13

Dsainati1

Commented On 28 Sep 2022 at 07:05:13

Dsainati1

Sync Stable Cadence

Description

Bring Stable Cadence branch up-to-date.


  • [ ] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 28 Sep 2022 at 06:48:49

Dsainati1

Commented On 28 Sep 2022 at 06:48:49

Dsainati1

Take argument labels into account when declaring members for nested declarations

Re-port of #1717 to Stable Cadence. It had been previously accidentally reverted by merging master into the Stable Cadence feature branch.


  • [ ] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 28 Sep 2022 at 05:46:25

Dsainati1

Commented On 28 Sep 2022 at 05:46:25

Dsainati1

Add language clarifying the type parameter's type in the private and public path iteration functions

Created On 28 Sep 2022 at 04:59:41
Create Branch
Dsainati1 In onflow/cadence Create Branchsainati/2011-iteration-docs

Dsainati1

Cadence, the resource-oriented smart contract programming language 🏃‍♂️

On 28 Sep 2022 at 04:58:51
Issue Comment

Dsainati1

Remove redundant `Type` parameter from `private` and `public` path storage iteration

The new storage iteration API for private and public paths has the same signature as the one for storage: ((Path, Type): Bool). However, in the case of private and public paths, this Type is always going to be a Link, which is both redundant and also an implementation detail of Cadence that we have not previously exposed to the user. We should change the signature to be just ((Path): Bool); if users wish to inspect the type of the capability stored at that path, they can use getCapability to inspect it.

Forked On 28 Sep 2022 at 04:47:33

Dsainati1

After investigating this, the implementation for Link already handles this by returning a Capability when its type is queried. We decided to keep the API as-is because it allows users to use the type parameter to query the Capability type without loading the capability itself.

Commented On 28 Sep 2022 at 04:47:33

Dsainati1

Improve reference expressions

Port of #1661 to Stable Cadence

Also:

  • Update documentation
  • Make parser-initalization errors non-syntax errors: they are implementation errors and not user errors.

  • [ ] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 28 Sep 2022 at 02:16:59

Dsainati1

Commented On 28 Sep 2022 at 02:16:59
Issue Comment

Dsainati1

Extensibility flip

Adds FLIP proposing adding Extensions to Cadence. See discussion in https://forum.onflow.org/t/extensibility/622 and https://github.com/onflow/cadence/issues/357


For contributor use:

  • [X] Targeted PR against master branch
  • [X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • [X] Updated relevant documentation
  • [X] Re-reviewed Files changed in the Github PR explorer
  • [X] Added appropriate labels

Forked On 27 Sep 2022 at 06:27:11

Dsainati1

I want to elaborate a little further on the difficulty I mentioned in the language design meeting with the Metadata use case. The core difficulty here is designing an API that allows a resource to iterate over its extensions/attachments without requiring it to know anything about those extensions/attachments in advance. In particular, we'd like for an NFT's implementation of the metadata standard to include any metadata on those attachments.

For a simplified example, let's imagine that implementing the metadata standard just involved having a .metadata() method that returned a String that contained the NFT's metadata. In order to include the metadata of its extensions/attachments, a resource would want to be able to call this metadata method on any of these extensions/attachments that implement this standard, and include all those Strings in the final String produced by its metadata method.

This would require a reference to all these extensions/attachments, either an array type [X] or an iteration function func iterExtensions(f ((extension X): Void)). Developers could then use a loop to iterate over that array, or call the iteration function to apply an operation to every extension/attachment on their resource. But what type should X be? If a resource knows nothing about what kind of extensions/attachments could be present on it, the only type that we could possibly use would be AnyStruct (or AnyResource, if attachments/extensions are resources). But if the type is this general, we can't do anything with it. Currently in Cadence there is no way to check whether a member exists (let alone exists with a specific type) on a value short of attempting a runtime cast to a type with that field. However, if we require the resource developer to attempt to cast X to the type of each extension/attachment that they wish to look for the metadata method on, this inherently requires them to know in advance what kinds of extensions/attachments they will have.

There are a couple options here, as I see it:

  1. We could add support for true runtime reflection, allowing users to ask whether an arbitrary value of type Any has a specific field with a specific type, and then allowing them to access that member once they have determined its type and value. This way users could check for the presence of the metadata method on each extension/attachment and call it if it is found. This is similar to how duck-typing works in a language like JavaScript or Python, and comes with all the dangers and footguns inherent in that style.

  2. We could add runtime interface conformance checking. Users could do a dynamic cast to an interface, like some interface Metadata that contains a metadata():String function type, and if successful would be able to use the resulting value as a value of that interface type. This is safer than the reflection example, but has more failure points. In particular, because Cadence typing is nominal rather than structural, developers of an attachment/extension would need to explicitly declare that they implement Metadata, and any extensions/attachments that have the metadata():String method but don't declare implementation of Metadata would be fail the dynamic cast.

  3. We could allow resource developers to require that any extensions/attachments implement an interface. This would ensure that developers of an extension/attachment for their resource include all the functionality in each extension/attachment that the resource developer expects, and thus make that functionality available to the resource developer. E.g., the resource developer could require that all its attachments/extensions implement Metadata, so then X would be easily known to be {Metadata}, making all the members on that type available on all the extensions/attachments during iteration. However, this also means that if the resource developer wishes to impose a new requirement on extensions/attachments, perhaps to support a new standard similar to how Metadata works, this would break all existing extensions/attachments on that resource until they update their code.

It is unclear to me what the best path forward is here. All of these have pros and cons.

Commented On 27 Sep 2022 at 06:27:11
Merge

Dsainati1

Make Void values constructible

Closes #2005

Description

Currently, the Void type is a little inconsistent - it serves as an implicit return value for procedures, but isn't constructible on its own despite being a first-class value. The only way to conjure up a Void value is to bind a name to a procedure call:

let v: Void = (fun() {})() 

In the REPL, Void values are currently printed as () (the empty tuple, similar to other languages with unit types) but writing () on its own results in a parse error. This PR introduces the following changes:

  1. Introduce the () literal, which corresponds to Void. This equivalence (where Void refers to the empty tuple) is inspired by Swift, where Void is just a type alias. If tuples are added to the language later on, Void could also become a type alias for the empty tuple, piggybacking off the same parsing mechanisms as n-ary tuples. Using these values is cheap, as all instances of Void point to the same singleton object. Though it's outside the scope of this PR, future optimizations could treat unit types as having zero-size and elide their creation altogether.

  2. Make Void values equatable, i.e.

() == () 

since equality is reflexive. This is a non-breaking change, as attempting to equate Void values previously resulted in an InvalidBinaryOperandsError.


  • [x] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Forked On 27 Sep 2022 at 03:27:58

Dsainati1

Can I still return `()` from a function with an implicit void return? I.e. is this legal: ``` fun emptyFunction() { return () } ``` Either way this deserves a test case.
On 27 Sep 2022 at 03:27:58

Dsainati1

Make Void values constructible

Closes #2005

Description

Currently, the Void type is a little inconsistent - it serves as an implicit return value for procedures, but isn't constructible on its own despite being a first-class value. The only way to conjure up a Void value is to bind a name to a procedure call:

let v: Void = (fun() {})() 

In the REPL, Void values are currently printed as () (the empty tuple, similar to other languages with unit types) but writing () on its own results in a parse error. This PR introduces the following changes:

  1. Introduce the () literal, which corresponds to Void. This equivalence (where Void refers to the empty tuple) is inspired by Swift, where Void is just a type alias. If tuples are added to the language later on, Void could also become a type alias for the empty tuple, piggybacking off the same parsing mechanisms as n-ary tuples. Using these values is cheap, as all instances of Void point to the same singleton object. Though it's outside the scope of this PR, future optimizations could treat unit types as having zero-size and elide their creation altogether.

  2. Make Void values equatable, i.e.

() == () 

since equality is reflexive. This is a non-breaking change, as attempting to equate Void values previously resulted in an InvalidBinaryOperandsError.


  • [x] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 27 Sep 2022 at 03:28:14

Dsainati1

Commented On 27 Sep 2022 at 03:28:14

Dsainati1

Make Void values constructible

Closes #2005

Description

Currently, the Void type is a little inconsistent - it serves as an implicit return value for procedures, but isn't constructible on its own despite being a first-class value. The only way to conjure up a Void value is to bind a name to a procedure call:

let v: Void = (fun() {})() 

In the REPL, Void values are currently printed as () (the empty tuple, similar to other languages with unit types) but writing () on its own results in a parse error. This PR introduces the following changes:

  1. Introduce the () literal, which corresponds to Void. This equivalence (where Void refers to the empty tuple) is inspired by Swift, where Void is just a type alias. If tuples are added to the language later on, Void could also become a type alias for the empty tuple, piggybacking off the same parsing mechanisms as n-ary tuples. Using these values is cheap, as all instances of Void point to the same singleton object. Though it's outside the scope of this PR, future optimizations could treat unit types as having zero-size and elide their creation altogether.

  2. Make Void values equatable, i.e.

() == () 

since equality is reflexive. This is a non-breaking change, as attempting to equate Void values previously resulted in an InvalidBinaryOperandsError.


  • [x] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 27 Sep 2022 at 03:28:14

Dsainati1

Commented On 27 Sep 2022 at 03:28:14

Dsainati1

Add documentations for testing framework: asserts and matchers

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Add docs about blockchain, running scripts and transactions

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Add docs on setting configurations and reading files

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Improve docs

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Document blockchain configurations

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Apply suggestions from code review

Co-authored-by: Bastian Müller bastian@axiomzen.co

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Add line breaks

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Convert to mdx

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

set access check mode, bring back log function

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

export functionality required by debugger

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

bring back SetDebugger function

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

optimize address location type ID

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

optimize transaction location type ID

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

optimize script location type ID

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

optimize Flow location type ID

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

lint

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Fix minor typos

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Update assert func argument label

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Merge branch 'master' of https://github.com/onflow/cadence into supun/test-framework-docs

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Fix configuration

Pushed On 26 Sep 2022 at 08:24:30

Dsainati1

Update LS to Cadence v0.27.0


  • [x] Targeted PR against master branch
  • [x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
  • [x] Code follows the standards mentioned here
  • [x] Updated relevant documentation
  • [x] Re-reviewed Files changed in the Github PR explorer
  • [x] Added appropriate labels

Merged On 26 Sep 2022 at 08:11:56

Dsainati1

Commented On 26 Sep 2022 at 08:11:56

Dsainati1

update FLIP with meeting feedback

Pushed On 26 Sep 2022 at 04:40:21
Issue Comment

Dsainati1

FLIP for `publish` and `claim` for capabilities

Adds a new proposal for a pair of API functions: publish and claim that are designed to address the capability bootstrapping use case detailed here https://github.com/onflow/cadence/issues/1951


For contributor use:

  • [X] Targeted PR against master branch
  • [X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • [X] Updated relevant documentation
  • [X] Re-reviewed Files changed in the Github PR explorer
  • [X] Added appropriate labels

Forked On 26 Sep 2022 at 03:45:43

Dsainati1

We had a public meeting about this FLIP today (Sept 26) and we settled on a few specific steps forward here:

  1. Spam and harassment via events or messages is the responsibility of the user actor (e.g. the wallet) to manage, rather than the protocol, so we will remove the allowlist, permit and unpermit sections of this proposal in favor of these things being handled off-chain. We will likely suggest to wallet or other user actor developers that they do not display publishing events as-is to users, and allow users to restrict who they see events from.

  2. publish, claim, unpublish should all emit an event to signify that a capability has been published or removed, containing the name, type, and receiver (in the case of publish) and the name and removing account (in the case of claim and unpublish). This will give accounts the information they need to claim resources when they are published for them.

  3. For now, the API will continue to be restricted to capabilities. In the future we may decide to expand this to resources, but this would not be a breaking change (whereas going from resources now to capabilities in the future would be).

  4. claim should remove the capability being claimed from the publisher's dictionary. While capabilities can be duplicated, so it would not be semantically wrong to leave a copy present, leaving the capability in place would require manual cleanup on the part of the publisher that is not desirable. It would also encourage a pattern where receivers would repeatedly claim capabilities stored on the publisher's account whenever they need them, in order to avoid paying for the storage for that capability themselves.

Commented On 26 Sep 2022 at 03:45:43
Issue Comment

Dsainati1

FLIP for `publish` and `claim` for capabilities

Adds a new proposal for a pair of API functions: publish and claim that are designed to address the capability bootstrapping use case detailed here https://github.com/onflow/cadence/issues/1951


For contributor use:

  • [X] Targeted PR against master branch
  • [X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • [X] Updated relevant documentation
  • [X] Re-reviewed Files changed in the Github PR explorer
  • [X] Added appropriate labels

Forked On 26 Sep 2022 at 02:46:55

Dsainati1

my point is that doing that is very easy already

I am not convinced that this is a particularly compelling argument; just because a bad practice is commonplace already does not excuse us as designers if we contribute to the problem by adding another vector for harassment.

Commented On 26 Sep 2022 at 02:46:55