Any attendee can add an agenda topic by creating a pull request on this file and adding more topics in the agenda below.
Agenda for this meeting will be to:
-
Review, discuss and clean up open FLIPs: onflow/cadence#3615
-
Summary of priorities for the Cadence team for this quarter
-
Add fields in update: onflow/flips#295
- originally onflow/flow#1097
- Dete:
- What about updating types arbitrarily?
- Might want to consider more general version instead of incremental
- Deniz:
- Against
- Good to limit scope
- Too complicated to implement (existing removed fields)
- Generic extra storage in all types?
- Supun:
- In the proposal also define how field can be prevented from getting removed (tombstoning) first
- Requirement to proceed
- Josh:
- Not very necessary, can already add fields, proposal just makes it more elegant
- Add fields to contracts: use account storage and add getter/setter
- "All or nothing": Allow it for all types, not just contracts
- Implications of storing additional data in existing values, in owners' accounts
- Not very necessary, can already add fields, proposal just makes it more elegant
- Who wants to champion this?
- Follow up with Austin
-
Cadence Date and Time: onflow/flips#245
- Get more feedback, currently just a draft
- Josh:
- Just to have a nice to have
- Currently mostly raw Unix timestamps
- Dete:
- Maybe bounty, managed by DevEx team
- Can be done purely in Cadence, does not need any internal knowlegde of or contributions to Cadence
- Useful, but not critical
- Low priority tag, "good first issue"
-
Cadence WebAssembly API: onflow/flips#256
- PoC is fairly complete
- TODO: limits, metering details
- Supun:
- Proposal is simple, "no-brainer"
- Should metering be part of FLIP?
- Janez:
- Next quarter: Recalibration of computation, can include this, no extra work
- Don't have to define metering, can mention it
- Can overestimate fuel for now
- Dete:
- In favour
- Not highest priority, but unlocks use-cases
- Deniz:
- In favour
-
Authorized Call: onflow/flips#198
- Dete:
- Discuss with author
- Maybe just confused by capabilities and we need better explanation or UX around it?
- Dete:
-
Extended Transaction Format: onflow/flips#41
- Check priority with Jeff?
- Dete:
- Close and reopen once there is a concrete proposal
- Currently a design discussion, not a concrete FLIP
- Follow up with Wallet team (Jeff)
- Not in a state where it can be implemented
- Icebox or close
-
Type removal pragma: onflow/flips#276
- Make decision
- Supun:
- Not as important anymore as it was during Cadence 1.0 migration, but still useful
- Already is possible to break stored values
- Josh:
- Useful, but not as important as adding fields
- Dete:
- Protections, preventing breakage not useful
- Need to be able to delete objects with "broken types"
- Need mechanism to lock down contract, make contract immutable
- Proposal does not make "breakability" problem worse (malicious developer), already multiple other mechanisms to break type
- Adds value to non-malicious developer
- Deniz:
- Bad, allows breaking existing stored values of users
- "Contract" should be contract
- Gio:
- What about storage iteration
- Accepted
-
Simple string interpolation: onflow/flips#289
- Deniz:
- In favour, very useful
- Supun:
- Separate syntax to differentiate interpolating strings from normal string literals?
- Bastian:
- Unnecessary to have separate syntax
- Dete:
- Modern developers don't understand cost of strings, especially safe strings
- We are in a constrained environment
- Useful for scripts
- Nervous about using strings in contracts and storage
- Need to think more about strings in general
- Josh:
- Highest priority
- Very useful for error message improvement in core contracts
- Improves current situation
- Accepted
- But also: Discussion on best practices around strings
- Deniz:
-
StructStringerinterface: onflow/flips#294- Discuss the concerns and make a decision
- Deniz:
- How to know if it's safe to call?
- Can panic
- Not trusted
- In favour
- Gio:
- Would be an issue if used as a dictionary key
- Supun:
- Accepted