You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/varnamedtuple.jl
+7-5Lines changed: 7 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -474,14 +474,16 @@ is `merge`, which recursively merges two `VarNamedTuple`s.
474
474
475
475
The there are two major limitations to indexing by VarNamedTuples:
476
476
477
-
* `VarName`s with `Colon`s, (e.g. `a[:]`) are not supported. This is because the meaning of `a[:]` is ambiguous if only some elements of `a`, say `a[1]` and `a[3]`, are defined.
478
-
* Any `VarNames` with IndexLenses` must have a consistent number of indices. That is, one cannot set `a[1]` and `a[1,2]` in the same `VarNamedTuple`.
477
+
* `VarName`s with `Colon`s, (e.g. `a[:]`) are not supported. This is because the meaning of
478
+
`a[:]` is ambiguous if only some elements of `a`, say `a[1]` and `a[3]`, are defined.
479
+
* Any `VarNames` with IndexLenses` must have a consistent number of indices. That is, one
480
+
cannot set `a[1]` and `a[1,2]` in the same `VarNamedTuple`.
479
481
480
482
`setindex!!` and `getindex` on `VarNamedTuple` are type stable as long as one does not store
481
-
heterogeneous data under different indices of the same symbol. That is, if one either
483
+
heterogeneous data under different indices of the same symbol. That is, if either
482
484
483
-
* sets `a[1]` and `a[2]` to be of different types, or
484
-
* sets `a[1].b` and `a[2].c`, without setting `a[1].c`. or `a[2].b`,
485
+
* one sets `a[1]` and `a[2]` to be of different types, or
486
+
* if `a[1]` and `a[2]` both exist, one sets `a[1].b` without setting `a[2].b`,
485
487
486
488
then getting values for `a[1]` or `a[2]` will not be type stable.
0 commit comments