bump version

Project.toml

@@ -1,7 +1,7 @@
 name = "EltypeExtensions"
 uuid = "583f92f5-06d6-4306-8236-316410defc98"
 authors = ["Tianyi Pu <[email protected]> and contributors"]
-version = "0.0.5"
+version = "0.1.0"
 
 [deps]
 LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"

README.md

@@ -16,19 +16,19 @@ The package is tested against `[Julia versions from 1.0 to 1.11]`X`[ubuntu, wind
 
 ## Introduction
 
-### `elconvert` and `_to_eltype`
-`elconvert(T, x)` works like `convert(T, x)`, except that `T` refers to the eltype of the result. This can be useful for generic codes.
+### `convert_eltype` and `_to_eltype`
+`convert_eltype(T, x)` works like `convert(T, x)`, except that `T` refers to the eltype of the result. This can be useful for generic codes.
 
-It should be always true that `elconvert(T, x) isa _to_eltype(T, typeof(x))`. However, since `elconvert` and `_to_eltype` use different routines, it's possible that the equality doesn't hold for some types. Please submit an issue or PR if that happens.
+It should be always true that `convert_eltype(T, x) isa _to_eltype(T, typeof(x))`. However, since `convert_eltype` and `_to_eltype` use different routines, it's possible that the equality doesn't hold for some types. Please submit an issue or PR if that happens.
 
-If `typeof(x)` is not in Base or stdlib, the package who owns the type should implement corresponding `_to_eltype` or `elconvert`. `elconvert` has fallbacks, in which case it could be unnecessary:
-- For a subtype of `AbstractArray`, `elconvert` calls the constructor `AbstractArray{T}` and `_to_eltype` returns `Array`.
-- For a subtype of `AbstractUnitRange`, `elconvert` calls the constructor `AbstractUnitRange{T}`.
-- For a subtype of `AbstractRange`, `elconvert` uses broadcast through `map`.
-- For a `Tuple`, `elconvert` uses dot broadcast.
-- For other types, `elconvert` calls `convert` and `_to_eltype`.
+If `typeof(x)` is not in Base or stdlib, the package who owns the type should implement corresponding `_to_eltype` or `convert_eltype`. `convert_eltype` has fallbacks, in which case it could be unnecessary:
+- For a subtype of `AbstractArray`, `convert_eltype` calls the constructor `AbstractArray{T}` and `_to_eltype` returns `Array`.
+- For a subtype of `AbstractUnitRange`, `convert_eltype` calls the constructor `AbstractUnitRange{T}`.
+- For a subtype of `AbstractRange`, `convert_eltype` uses broadcast through `map`.
+- For a `Tuple`, `convert_eltype` uses dot broadcast.
+- For other types, `convert_eltype` calls `convert` and `_to_eltype`.
 
-However, `_to_eltype` must be implemented for each type to support `baseconvert` and `precisionconvert`. The following types from Base and stdlib are explicitly supported by `_to_eltype`:
+However, `_to_eltype` must be implemented for each type to support `convert_basetype` and `convert_precisiontype`. The following types from Base and stdlib are explicitly supported by `_to_eltype`:
 ```
 AbstractArray, AbstractDict, AbstractSet, Adjoint, Bidiagonal, BitArray,
 CartesianIndices, Diagonal, Dict, Hermitian, Set, StepRangeLen, Symmetric,
@@ -46,8 +46,8 @@ The `basetype` is used for nested collections, where `eltype` is repeatedly appl
 
 where `some` can be `el`, `base` and `precision`.
 
-### On `precisionconvert`
-`precisionconvert` accepts an optional third argument `prec`. 
+### On `convert_precisiontype`
+`convert_precisiontype` accepts an optional third argument `prec`. 
 - When `T` has static precision, `prec` has no effect.
-- When `T` has dynamic precision, `prec` specifies the precision of conversion. When `prec` is not provided, the precision is decided by the external setup from `T`. The difference is significant when `precisionconvert` is called by another function. See the document for an example.
+- When `T` has dynamic precision, `prec` specifies the precision of conversion. When `prec` is not provided, the precision is decided by the external setup from `T`. The difference is significant when `convert_precisiontype` is called by another function. See the document for an example.
 - When `T` is an integer, the conversion will dig into `Rational` as well. In contrast, since `Rational` as a whole is more "precise" than an integer, `precisiontype` doesn't unwrap `Rational`.