add identity field to AuthAccount

[bjartek]

Closes #423

Description

Add an Identity type and a field to AuthAccount that retuns a reference to it.

---

• [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
• [ ] Added appropriate labels

[codecov-commenter]

Codecov Report

Merging #1363 (1d1c31c) into master (f8a2df8) will increase coverage by 0.01%. The diff coverage is 83.67%.

@@            Coverage Diff             @@
##           master    #1363      +/-   ##
==========================================
+ Coverage   75.93%   75.94%   +0.01%     
==========================================
  Files         279      280       +1     
  Lines       38686    38735      +49     
==========================================
+ Hits        29375    29418      +43     
- Misses       7967     7973       +6     
  Partials     1344     1344              

Flag	Coverage Δ
unittests	75.94% <83.67%> (+0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
runtime/interpreter/primitivestatictype.go	71.10% <0.00%> (-1.33%)	:arrow_down:
runtime/interpreter/primitivestatictype_string.go	66.66% <ø> (ø)
runtime/interpreter/account.go	91.11% <77.77%> (-2.06%)	:arrow_down:
runtime/sema/authaccount_type.go	100.00% <100.00%> (ø)
runtime/sema/identity_type.go	100.00% <100.00%> (ø)
runtime/sema/type.go	88.46% <100.00%> (+<0.01%)	:arrow_up:
runtime/sema/check_event_declaration.go	100.00% <0.00%> (+5.12%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f8a2df8...1d1c31c. Read the comment docs.

[bjartek]

@turbolent do you have any hints on how to go forward here, There is quite a lot boilerplate and I am not sure I have finished it all.

[joshuahannan]

I don't know if this makes sense. It encourages msg.sender access control list patterns that we have explicitly tried to avoid in Cadence.

[bjartek]

My usecase for this is to add context to events, since in some scenarios it is really hard to add "the other side" to an event.

[turbolent]

@joshuahannan Thank you for your feedback. Maybe we should propose such an addition through a FLIP?

[joshuahannan]

Maybe a FLIP would be good. Though I guess it wouldn't hurt to have a feature like this on the chance that it could be useful, but I worry that people would use it the wrong way. But that might not be the responsibility of the language to enforce and could be something that is just viewed as a best practice

[bluesign]

I agree with @joshuahannan in this case, but also I feel like we lost the war on msg.sender pattern with resource owner already.

This will be more clear vs people abusing resource owner for sure.

But eventually FLIP can be good to see other alternatives, community use cases etc.

[turbolent]

@bjartek Would you be willing to create a FLIP for this? That way we could get community consent on adding this feature. It would be much appreciated :-)

[bjartek]

https://github.com/onflow/flow/pull/945

[turbolent]

The FLIP proposing the addition of this feature has been rejected, so closing this implementation PR.

Thank you very much for your PR @bjartek, it sparked a very fruitful discussion, and hopefully an even better solution to the problem it tries to solve. 🙏