[−][src]Enum trust_dns_proto::rr::record_data::RData
Record data enum variants
RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION, November 1987
3.3. Standard RRs
The following RR definitions are expected to occur, at least
potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.
<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length. <character-string> is a single
length octet followed by that number of characters. <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).
Variants
A(Ipv4Addr)-- RFC 1035 -- Domain Implementation and Specification November 1987
3.4. Internet specific RRs
3.4.1. A RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS A 32 bit Internet address.
Hosts that have multiple Internet addresses will have multiple A
records.
A records cause no additional section processing. The RDATA section of
an A line in a master file is an Internet address expressed as four
decimal numbers separated by dots without any imbedded spaces (e.g.,
"10.2.0.52" or "192.0.5.6").
AAAA(Ipv6Addr)-- RFC 1886 -- IPv6 DNS Extensions December 1995
2.2 AAAA data format
A 128 bit IPv6 address is encoded in the data portion of an AAAA
resource record in network byte order (high-order byte first).
ANAME(Name)2. The ANAME resource record
This document defines the "ANAME" DNS resource record type, with RR
TYPE value [TBD].
2.1. Presentation and wire format
The ANAME presentation format is identical to that of CNAME
[RFC1033]:
owner ttl class ANAME target
CAA(CAA)-- RFC 6844 Certification Authority Authorization January 2013
5.1. Syntax
A CAA RR contains a single property entry consisting of a tag-value
pair. Each tag represents a property of the CAA record. The value
of a CAA property is that specified in the corresponding value field.
A domain name MAY have multiple CAA RRs associated with it and a
given property MAY be specified more than once.
The CAA data field contains one property entry. A property entry
consists of the following data fields:
+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags | Tag Length = n |
+----------------+----------------+...+---------------+
| Tag char 0 | Tag char 1 |...| Tag char n-1 |
+----------------+----------------+...+---------------+
+----------------+----------------+.....+----------------+
| Value byte 0 | Value byte 1 |.....| Value byte m-1 |
+----------------+----------------+.....+----------------+
Where n is the length specified in the Tag length field and m is the
remaining octets in the Value field (m = d - n - 2) where d is the
length of the RDATA section.
CNAME(Name) 3.3. Standard RRs
The following RR definitions are expected to occur, at least
potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.
<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length. <character-string> is a single
length octet followed by that number of characters. <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).
3.3.1. CNAME RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME A <domain-name> which specifies the canonical or primary
name for the owner. The owner name is an alias.
CNAME RRs cause no additional section processing, but name servers may
choose to restart the query at the canonical name in certain cases. See
the description of name server logic in [RFC-1034] for details.
MX(MX)3.3.9. MX RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE A 16 bit integer which specifies the preference given to
this RR among others at the same owner. Lower values
are preferred.
EXCHANGE A <domain-name> which specifies a host willing to act as
a mail exchange for the owner name.
MX records cause type A additional section processing for the host
specified by EXCHANGE. The use of MX RRs is explained in detail in
[RFC-974].
NAPTR(NAPTR)RFC 3403 DDDS DNS Database, October 2002
4.1 Packet Format
The packet format of the NAPTR RR is given below. The DNS type code
for NAPTR is 35.
The packet format for the NAPTR record is as follows
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
<character-string> and <domain-name> as used here are defined in RFC
1035 [7].
ORDER
A 16-bit unsigned integer specifying the order in which the NAPTR
records MUST be processed in order to accurately represent the
ordered list of Rules. The ordering is from lowest to highest.
If two records have the same order value then they are considered
to be the same rule and should be selected based on the
combination of the Preference values and Services offered.
PREFERENCE
Although it is called "preference" in deference to DNS
terminology, this field is equivalent to the Priority value in the
DDDS Algorithm. It is a 16-bit unsigned integer that specifies
the order in which NAPTR records with equal Order values SHOULD be
processed, low numbers being processed before high numbers. This
is similar to the preference field in an MX record, and is used so
domain administrators can direct clients towards more capable
hosts or lighter weight protocols. A client MAY look at records
with higher preference values if it has a good reason to do so
such as not supporting some protocol or service very well.
The important difference between Order and Preference is that once
a match is found the client MUST NOT consider records with a
different Order but they MAY process records with the same Order
but different Preferences. The only exception to this is noted in
the second important Note in the DDDS algorithm specification
concerning allowing clients to use more complex Service
determination between steps 3 and 4 in the algorithm. Preference
is used to give communicate a higher quality of service to rules
that are considered the same from an authority standpoint but not
from a simple load balancing standpoint.
It is important to note that DNS contains several load balancing
mechanisms and if load balancing among otherwise equal services
should be needed then methods such as SRV records or multiple A
records should be utilized to accomplish load balancing.
FLAGS
A <character-string> containing flags to control aspects of the
rewriting and interpretation of the fields in the record. Flags
are single characters from the set A-Z and 0-9. The case of the
alphabetic characters is not significant. The field can be empty.
It is up to the Application specifying how it is using this
Database to define the Flags in this field. It must define which
ones are terminal and which ones are not.
SERVICES
A <character-string> that specifies the Service Parameters
applicable to this this delegation path. It is up to the
Application Specification to specify the values found in this
field.
REGEXP
A <character-string> containing a substitution expression that is
applied to the original string held by the client in order to
construct the next domain name to lookup. See the DDDS Algorithm
specification for the syntax of this field.
As stated in the DDDS algorithm, The regular expressions MUST NOT
be used in a cumulative fashion, that is, they should only be
applied to the original string held by the client, never to the
domain name p roduced by a previous NAPTR rewrite. The latter is
tempting in some applications but experience has shown such use to
be extremely fault sensitive, very error prone, and extremely
difficult to debug.
REPLACEMENT
A <domain-name> which is the next domain-name to query for
depending on the potential values found in the flags field. This
field is used when the regular expression is a simple replacement
operation. Any value in this field MUST be a fully qualified
domain-name. Name compression is not to be used for this field.
This field and the REGEXP field together make up the Substitution
Expression in the DDDS Algorithm. It is simply a historical
optimization specifically for DNS compression that this field
exists. The fields are also mutually exclusive. If a record is
returned that has values for both fields then it is considered to
be in error and SHOULD be either ignored or an error returned.
NULL(NULL)3.3.10. NULL RDATA format (EXPERIMENTAL)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Anything at all may be in the RDATA field so long as it is 65535 octets
or less.
NULL records cause no additional section processing. NULL RRs are not
allowed in master files. NULLs are used as placeholders in some
experimental extensions of the DNS.
NS(Name)3.3.11. NS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME A <domain-name> which specifies a host which should be
authoritative for the specified class and domain.
NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of the
zone in which they reside for glue information.
The NS RR states that the named host should be expected to have a zone
starting at owner name of the specified class. Note that the class may
not indicate the protocol family which should be used to communicate
with the host, although it is typically a strong hint. For example,
hosts which are name servers for either Internet (IN) or Hesiod (HS)
class information are normally queried using IN class protocols.
OPENPGPKEY(OPENPGPKEY)The RDATA portion of an OPENPGPKEY resource record contains a single
value consisting of a Transferable Public Key formatted as specified
in [RFC4880].
OPT(OPT)RFC 6891 EDNS(0) Extensions April 2013
6.1.2. Wire Format
+------------+--------------+------------------------------+
| Field Name | Field Type | Description |
+------------+--------------+------------------------------+
| NAME | domain name | MUST be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+
The variable part of an OPT RR may contain zero or more options in
the RDATA. Each option MUST be treated as a bit field. Each option
is encoded as:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
PTR(Name)3.3.12. PTR RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTRDNAME A <domain-name> which points to some location in the
domain name space.
PTR records cause no additional section processing. These RRs are used
in special domains to point to some other location in the domain space.
These records are simple data, and don't imply any special processing
similar to that performed by CNAME, which identifies aliases. See the
description of the IN-ADDR.ARPA domain for an example.
SOA(SOA)3.3.13. SOA RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MNAME The <domain-name> of the name server that was the
original or primary source of data for this zone.
RNAME A <domain-name> which specifies the mailbox of the
person responsible for this zone.
SERIAL The unsigned 32 bit version number of the original copy
of the zone. Zone transfers preserve this value. This
value wraps and should be compared using sequence space
arithmetic.
REFRESH A 32 bit time interval before the zone should be
refreshed.
RETRY A 32 bit time interval that should elapse before a
failed refresh should be retried.
EXPIRE A 32 bit time value that specifies the upper limit on
the time interval that can elapse before the zone is no
longer authoritative.
MINIMUM The unsigned 32 bit minimum TTL field that should be
exported with any RR from this zone.
SOA records cause no additional section processing.
All times are in units of seconds.
Most of these fields are pertinent only for name server maintenance
operations. However, MINIMUM is used in all query operations that
retrieve RRs from a zone. Whenever a RR is sent in a response to a
query, the TTL field is set to the maximum of the TTL field from the RR
and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
bound on the TTL field for all RRs in a zone. Note that this use of
MINIMUM should occur when the RRs are copied into the response and not
when the zone is loaded from a master file or via a zone transfer. The
reason for this provison is to allow future dynamic update facilities to
change the SOA RR with known semantics.
SRV(SRV)RFC 2782 DNS SRV RR February 2000
The format of the SRV RR
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
SSHFP(SSHFP)3.1. The SSHFP RDATA Format
The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
type and the fingerprint of the public host key.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | fp type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ fingerprint /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1. Algorithm Number Specification
This algorithm number octet describes the algorithm of the public
key. The following values are assigned:
Value Algorithm name
----- --------------
0 reserved
1 RSA
2 DSS
Reserving other types requires IETF consensus [4].
3.1.2. Fingerprint Type Specification
The fingerprint type octet describes the message-digest algorithm
used to calculate the fingerprint of the public key. The following
values are assigned:
Value Fingerprint type
----- ----------------
0 reserved
1 SHA-1
Reserving other types requires IETF consensus [4].
For interoperability reasons, as few fingerprint types as possible
should be reserved. The only reason to reserve additional types is
to increase security.
3.1.3. Fingerprint
The fingerprint is calculated over the public key blob as described
in [7].
The message-digest algorithm is presumed to produce an opaque octet
string output, which is placed as-is in the RDATA fingerprint field.
The algorithm and fingerprint type values have been updated in RFC 6594 and RFC 7479.
TLSA(TLSA)RFC 6698, DNS-Based Authentication for TLS
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert. Usage | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ Certificate Association Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TXT(TXT)3.3.14. TXT RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TXT-DATA One or more <character-string>s.
TXT RRs are used to hold descriptive text. The semantics of the text
depends on the domain where it is found.
UnknownUnknown RecordData is for record types not supported by Trust-DNS
Fields of Unknown
ZEROThis corresponds to a record type of 0, unspecified
Methods
impl RData[src]
pub fn as_a(&self) -> Option<&Ipv4Addr>[src]
Optionally returns references to the inner fields if this is a RData::A, otherwise None
pub fn as_aaaa(&self) -> Option<&Ipv6Addr>[src]
Optionally returns references to the inner fields if this is a RData::AAAA, otherwise None
pub fn as_aname(&self) -> Option<&Name>[src]
Optionally returns references to the inner fields if this is a RData::ANAME, otherwise None
pub fn as_caa(&self) -> Option<&CAA>[src]
Optionally returns references to the inner fields if this is a RData::CAA, otherwise None
pub fn as_cname(&self) -> Option<&Name>[src]
Optionally returns references to the inner fields if this is a RData::CNAME, otherwise None
pub fn as_mx(&self) -> Option<&MX>[src]
Optionally returns references to the inner fields if this is a RData::MX, otherwise None
pub fn as_naptr(&self) -> Option<&NAPTR>[src]
Optionally returns references to the inner fields if this is a RData::NAPTR, otherwise None
pub fn as_null(&self) -> Option<&NULL>[src]
Optionally returns references to the inner fields if this is a RData::NULL, otherwise None
pub fn as_ns(&self) -> Option<&Name>[src]
Optionally returns references to the inner fields if this is a RData::NS, otherwise None
pub fn as_openpgpkey(&self) -> Option<&OPENPGPKEY>[src]
Optionally returns references to the inner fields if this is a RData::OPENPGPKEY, otherwise None
pub fn as_opt(&self) -> Option<&OPT>[src]
Optionally returns references to the inner fields if this is a RData::OPT, otherwise None
pub fn as_ptr(&self) -> Option<&Name>[src]
Optionally returns references to the inner fields if this is a RData::PTR, otherwise None
pub fn as_soa(&self) -> Option<&SOA>[src]
Optionally returns references to the inner fields if this is a RData::SOA, otherwise None
pub fn as_srv(&self) -> Option<&SRV>[src]
Optionally returns references to the inner fields if this is a RData::SRV, otherwise None
pub fn as_sshfp(&self) -> Option<&SSHFP>[src]
Optionally returns references to the inner fields if this is a RData::SSHFP, otherwise None
pub fn as_tlsa(&self) -> Option<&TLSA>[src]
Optionally returns references to the inner fields if this is a RData::TLSA, otherwise None
pub fn as_txt(&self) -> Option<&TXT>[src]
Optionally returns references to the inner fields if this is a RData::TXT, otherwise None
pub fn as_unknown(&self) -> Option<(&u16, &NULL)>[src]
Optionally returns references to the inner fields if this is a RData::Unknown, otherwise None
pub fn as_zero(&self) -> Option<()>[src]
Optionally returns references to the inner fields if this is a RData::ZERO, otherwise None
impl RData[src]
pub fn read(
decoder: &mut BinDecoder,
record_type: RecordType,
rdata_length: Restrict<u16>
) -> ProtoResult<Self>[src]
decoder: &mut BinDecoder,
record_type: RecordType,
rdata_length: Restrict<u16>
) -> ProtoResult<Self>
Read the RData from the given Decoder
pub fn emit(&self, encoder: &mut BinEncoder) -> ProtoResult<()>[src]
RFC 4034, DNSSEC Resource Records, March 2005
6.2. Canonical RR Form
For the purposes of DNS security, the canonical form of an RR is the
wire format of the RR where:
...
3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
SRV, DNAME, A6, RRSIG, or (rfc6840 removes NSEC), all uppercase
US-ASCII letters in the DNS names contained within the RDATA are replaced
by the corresponding lowercase US-ASCII letters;
Canonical name form for all non-1035 records: RFC 3579
4. Domain Name Compression
RRs containing compression pointers in the RDATA part cannot be
treated transparently, as the compression pointers are only
meaningful within the context of a DNS message. Transparently
copying the RDATA into a new DNS message would cause the compression
pointers to point at the corresponding location in the new message,
which now contains unrelated data. This would cause the compressed
name to be corrupted.
To avoid such corruption, servers MUST NOT compress domain names
embedded in the RDATA of types that are class-specific or not well-
known. This requirement was stated in [RFC1123] without defining the
term "well-known"; it is hereby specified that only the RR types
defined in [RFC1035] are to be considered "well-known".
The specifications of a few existing RR types have explicitly allowed
compression contrary to this specification: [RFC2163] specified that
compression applies to the PX RR, and [RFC2535] allowed compression
in SIG RRs and NXT RRs records. Since this specification disallows
compression in these cases, it is an update to [RFC2163] (section 4)
and [RFC2535] (sections 4.1.7 and 5.2).
Receiving servers MUST decompress domain names in RRs of well-known
type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
NXT, NAPTR, and SRV (although the current specification of the SRV RR
in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
servers following that earlier specification are still in use).
Future specifications for new RR types that contain domain names
within their RDATA MUST NOT allow the use of name compression for
those names, and SHOULD explicitly state that the embedded domain
names MUST NOT be compressed.
As noted in [RFC1123], the owner name of an RR is always eligible for
compression.
...
As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6.
...
pub fn to_record_type(&self) -> RecordType[src]
Converts this to a Recordtype
pub fn to_ip_addr(&self) -> Option<IpAddr>[src]
If this is an A or AAAA record type, then an IpAddr will be returned
Trait Implementations
impl PartialEq<RData> for RData[src]
impl Clone for RData[src]
fn clone(&self) -> RData[src]
fn clone_from(&mut self, source: &Self)1.0.0[src]
Performs copy-assignment from source. Read more
impl Ord for RData[src]
fn cmp(&self, other: &Self) -> Ordering[src]
fn max(self, other: Self) -> Self1.21.0[src]
Compares and returns the maximum of two values. Read more
fn min(self, other: Self) -> Self1.21.0[src]
Compares and returns the minimum of two values. Read more
fn clamp(self, min: Self, max: Self) -> Self[src]
🔬 This is a nightly-only experimental API. (
clamp)Restrict a value to a certain interval. Read more
impl Eq for RData[src]
impl PartialOrd<RData> for RData[src]
fn partial_cmp(&self, other: &RData) -> Option<Ordering>[src]
#[must_use]
fn lt(&self, other: &Rhs) -> bool1.0.0[src]
#[must_use]
fn lt(&self, other: &Rhs) -> boolThis method tests less than (for self and other) and is used by the < operator. Read more
#[must_use]
fn le(&self, other: &Rhs) -> bool1.0.0[src]
#[must_use]
fn le(&self, other: &Rhs) -> boolThis method tests less than or equal to (for self and other) and is used by the <= operator. Read more
#[must_use]
fn gt(&self, other: &Rhs) -> bool1.0.0[src]
#[must_use]
fn gt(&self, other: &Rhs) -> boolThis method tests greater than (for self and other) and is used by the > operator. Read more
#[must_use]
fn ge(&self, other: &Rhs) -> bool1.0.0[src]
#[must_use]
fn ge(&self, other: &Rhs) -> boolThis method tests greater than or equal to (for self and other) and is used by the >= operator. Read more
impl Debug for RData[src]
Auto Trait Implementations
Blanket Implementations
impl<T> From<T> for T[src]
impl<T> ToOwned for T where
T: Clone, [src]
T: Clone,
type Owned = T
The resulting type after obtaining ownership.
fn to_owned(&self) -> T[src]
fn clone_into(&self, target: &mut T)[src]
impl<T, U> Into<U> for T where
U: From<T>, [src]
U: From<T>,
impl<T, U> TryFrom<U> for T where
U: Into<T>, [src]
U: Into<T>,
type Error = Infallible
The type returned in the event of a conversion error.
fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>[src]
impl<T, U> TryInto<U> for T where
U: TryFrom<T>, [src]
U: TryFrom<T>,
type Error = <U as TryFrom<T>>::Error
The type returned in the event of a conversion error.
fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>[src]
impl<T> Borrow<T> for T where
T: ?Sized, [src]
T: ?Sized,
impl<T> BorrowMut<T> for T where
T: ?Sized, [src]
T: ?Sized,
fn borrow_mut(&mut self) -> &mut T[src]
impl<T> Any for T where
T: 'static + ?Sized, [src]
T: 'static + ?Sized,