withoutboats

extern crate futures;                                                                                                       

use std::str::FromStr;

use futures::{IntoFuture, Future};

fn foo<'a, T: Foo>(string: &'a str) -> Box<Future<Item = T, Error = ()> + 'a> {
    Box::new(string.parse().into_future()
                           .or_else(|_| Err(()))
                           .and_then(|id| Foo::from_id(&id)))

withoutboats

extern crate futures;

use futures::Future;

pub trait Foo: 'static {
    fn parse(string: String) -> Box<Future<Item = Self, Error = ()>>;
}

pub trait Bar: 'static {                                                                                                                                                                       
    type Id: Foo;

withoutboats

This document is the result of conversations that came out of this tweet: https://twitter.com/withoutboats/status/814201265575981056

# Rust's module system is too confusing

Empirically, very many new users of Rust are confused by Rust's module system. This is unfortunate:  Rust's module system is not particularly innovative or powerful; it is intended only to provide fairly standard privacy and namespacing support. Too much of new users' attention is being pulled by this system as it exists today.

This document presents an hypothesis of the cause of the confusion, and an attempt to mitigate that confusion by instituting a practice that is more similar to mainstream languages. We believe this problem is caused by the confluence of a several well-motivated design decisions that have created a very unusual system, and the solution is to require less declarations by leveraging ambient information in a manner more similar to how other languages' module systems work.

## Rust requires users to build an explicit 

withoutboats

#[macro_use] extern crate cargonauts;

use cargonauts::futures::{Future, future};
use cargonauts::resources::{Resource, Environment, Error};
use cargonauts::methods::Get;
use cargonauts::formats::Debug;

routes! {
    resource Echo {
        method Get in Debug;

withoutboats

#[macro_use] extern crate cargonauts;

use cargonauts::futures::{Future, future};
use cargonauts::resources::{Resource, Environment, Error};
use cargonauts::methods::Get;
use cargonauts::formats::Debug;

routes! {
    resource Echo {
        method Get in Debug;

withoutboats

#[macro_use] extern crate cargonauts;

use cargonauts::futures::{Future, future};
use cargonauts::resources::{Resource, Environment, Error};
use cargonauts::methods::Get;
use cargonauts::formats::Debug;

routes! {
    resource Echo {
        method Get in Debug;

withoutboats

Network services WG

---

Network services WG

1. Async IO
2. Library support for network services

---

withoutboats

Goal:

trait MyTrait {
    async fn foo(&self) -> i32;
}

impl MyTrait for MyType {
    async fn foo(&self) -> i32 {
 /* ... * /

withoutboats

Async Methods II: object safety

(Note: this is posted as a gist because my primary blog host is having some trouble today, and I can't get my blog to deploy. It will be on my blog eventually.)

[Last time][async-methods-i], we introduced the idea of async methods, and talked about how they would be implemented: as a kind of anonymous associated type on the trait that declares the method, which corresponds to a different, anonymous future type for each implementation of that method. Starting this

withoutboats

We don't need a need a new error trait if we just fix std::error::Error

Our great anguish around error handling is the incorrectness of the Error trait. Here's an easy way to solve the problem: fix the error trait. Literally: just change the existing trait so that it is correct.

Step 1: Remove description (DONE)

Description is already being deprecated, with a default method provided. Done and done.

Step 2: Add backtrace (TRIVIAL)