#28 Adds discussion of location propagation #34
Conversation
Attempts to clarify what the located type does and how it would be used to model existing solidity types and the future plans for explicit data locations.
| ##### Location Propagation | ||
|
|
||
| Reference types (that is, those types for which data location is relevant: `mapping`, `array`, | ||
| `static_array`, or `struct`) do **not** explicitly include location information. |
There was a problem hiding this comment.
Not directly related to the PR, but this makes me wonder - do we want to have a distinct type representing array slices? Solidity does have one, though it's not nameable and values of these types are used pretty much like arrays so it's not very apparent to the user. Might be relevant to a debugger though.
| What follows is an attempt at formal rigor. | ||
| Define a "well-located" type description _wt_ to be an entry | ||
| in the `types` array where the following condition is true: any reference type (`mapping`, `array`, | ||
| `static_array`, or `struct`) reachable from _wt_ must encounter at least one `located` type. |
There was a problem hiding this comment.
I think the spec should not limit this to specific sorts of types. Solidity already allows more - you can have located value types too, e.g. uints in storage. You cannot have local variables storing references to them, but that's a bit of an artificial restriction and some languages might even allow that. In fact we're currently in the process of redesigning how references work in Solidity and it's likely that we'll relax this restriction ourselves.
There was a problem hiding this comment.
Actually, being a reference and having a location are two distinct concepts. Like, a variable can be of a reference type or of a value type. And the target of the reference always has some location. For local variables that's just "stack" (though stack-to-memory mover mechanism complicates that notion a bit).
Solidity tries hard to hide this distinction and I wonder if it should be precisely reflected in the spec or not. It's all at the level of implementation details. On the other hand, these details are probably relevant to debuggers.
There was a problem hiding this comment.
I can confirm that these details would have been enormously helpful many years ago when @truffle/debugger was getting started :)
docs/source/format.md
Outdated
| The downside of this choice is that not all entries in the `types` array have an unambigous interpretation, | ||
| only those that meet the criteria of well-located given above. |
There was a problem hiding this comment.
I wouldn't really call it a downside. If every type in the language has to ultimately have a location, the spec could require that there exists a well-located version of it somewhere in the types array. And if not, then it's actually an advantage because we it lets us express types generic with regard to location (which will be a part of Solidity in the future).
Co-authored-by: Kamil Śliwak <[email protected]>
Attempts to clarify what the located type does and how it would be used to model existing solidity types and the future plans for explicit data locations.
Once again tagging @cameel because I can't request a review.
Closes #28.