leoyvens

Proposal for named optional arguments

Motivation

Highly customizable APIs need to somehow expose a long list of parameters that may be set, and will want to add new parameters in a backwards compatible way. Optional arguments allow that to be expressed in a single function.

From the caller side, you may ergonomically provide any subset of the optional arguments and are able to express your own uncertainty about the value. Reasoning about call sites remains simple as it's easy to tell if you're dealing with optional arguments or not.

In the ecosystem, many uses of the builder pattern can be identified as a need for this feature.

Relation with named arguments

This RFC proposes that optional arguments be named. It does not propose named arguments as a general feature, leaving that as an extension. The reason to propose optional arguments first and named arguments as an extension is that optional arguments add less reasoning complexity than named aguments. [As a wise man once put it](https://inter

leoyvens

#[allow(unused_imports)]
#[macro_use]
extern crate lazy_static;

#[cfg(test)]
mod tests {
    use std::sync::{Mutex, MutexGuard, Once, ONCE_INIT};

    /// Substitua String pelo tipo da sua conexão.
    lazy_static! {

leoyvens

• Feature Name: default_type_parameter_fallback_take_two
• Start Date: (fill me in with today's date, YYYY-MM-DD)
• RFC PR: (leave this empty)
• Rust Issue: (leave this empty)

Summary

Rust already allows us to set defaults for type parameters in type definitions, as in:

leoyvens

Grep rustc for "=> break" and "=> continue":

Summary:
-- Result or Option cases -- 36 counts
-- Not Result or Option -- 10 counts
-- Requires `if` guard -- 4 counts

-- Result or Option cases - 35 counts
let output = match prog {
    Ok(ref output) => output,

leoyvens

## Grafting onto Existing Subgraphs

When a subgraph is first deployed, it starts indexing events at the genesis block
of the corresponding chain (or at the `startBlock` defined with each data source)
In some circumstances, it is beneficial to reuse the data from an existing
subgraph and start indexing at a much later block. This mode of indexing is
called _Grafting_. Grafting is, for example, useful during development to get
past simple errors in the mappings quickly, or to temporarily get an existing
subgraph working again after it has failed.

leoyvens

Grafting onto Existing Subgraphs

When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the startBlock defined with each data source) In some circumstances, it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called Grafting. Grafting is, for example, useful during development to get past simple errors in the mappings quickly, or to temporarily get an existing subgraph working again after it has failed.