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
Currently, parse(T, str) basically defaults to T(str) which doesn't seem ideal. Especially with #72, we may want to use parse more extensively and reserve constructors for explicit type construction.
Base on the julia docs this seems like what we want:
Constructors are explicit, but may manipulate values as necessary.
convert should be lossless (e.g., convert(String, convert(::PathType, str))) == str)
parse/tryparse can be lossy, but are explicitly for parsing string representations of paths)
In theory, if you don't expect anyone to explicitly construct your type and folks are just relying on internal default behaviour of join, Path, p"" then a new type could probably just use the default constructor and only implement parse(T, str).
The text was updated successfully, but these errors were encountered:
Currently,
parse(T, str)
basically defaults toT(str)
which doesn't seem ideal. Especially with #72, we may want to useparse
more extensively and reserve constructors for explicit type construction.Base on the julia docs this seems like what we want:
convert
should be lossless (e.g.,convert(String, convert(::PathType, str))) == str
)parse
/tryparse
can be lossy, but are explicitly for parsing string representations of paths)In theory, if you don't expect anyone to explicitly construct your type and folks are just relying on internal default behaviour of
join
,Path
,p""
then a new type could probably just use the default constructor and only implementparse(T, str)
.The text was updated successfully, but these errors were encountered: