Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bound methods #141

Closed
thejoshwolfe opened this issue Apr 20, 2016 · 2 comments
Closed

bound methods #141

thejoshwolfe opened this issue Apr 20, 2016 · 2 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@thejoshwolfe
Copy link
Sponsor Contributor

struct Rand {
  fn by_val_this(rand: Rand) -> bool {...}
  fn next_unsafe(rand: &Rand) -> u32 {...}
  fn next_safe  (rand: &Rand) -> u32 {...}
  fn const_pointer_this(rand: &const Rand) -> u32 {...}
  fn fill_array(rand: &Rand, array: []u32) {...}
  // generic methods:
  fn range_inclusive(t: type)(rand: &Rand, min  : t, max: t) -> t {...}
  fn range_exclusive(t: type)(rand: &Rand, start: t, end: t) -> t {...}
}

fn main() {
  var rand = Rand{};
  // this stuff already works:
  rand.by_val_this();        // equivalent to `Rand.by_val_this(rand)`
  rand.next_unsafe();        // equivalent to `Rand.next_unsafe(&rand)`
  rand.const_pointer_this(); // equivalent to `Rand.const_pointer_this(&rand)`

  var preferences = read_preferences_at_runtime();

  const bound_fill_array: fn.(&Rand, []u32) = rand.fill_array;
  // implicit type is:
  // struct fn.(&Rand, []u32) {
  //   func: fn(&Rand, []u32),
  //   this: &Rand,
  // }
  // value is `{Rand.fill_array, rand}`
  var buffer = []u32{0, 0, 0, 0};
  bound_fill_array(buffer); // equivalent to `bound_fill_array.func(bound_fill_array.this, buffer)`

  const bound_next_func: fn.(&Rand)->u32 = if (preferences.safety) rand.next_safe else rand.next_unsafe;
  // implicit type is:
  // struct fn.(&Rand)->u32 {
  //   func: fn(&Rand)->u32,
  //   this: &Rand,
  // }
  bound_next_func(); // equivalent to `bound_next_func.func(bound_next_func.this)`

  // error: generic functions have to be instantiated at compile time
  //const range_func: fn.(t: type)(&Rand, t, t) = if (preferences.inclusivity) rand.range_inclusive else rand.range_exclusive;

  const range_func: fn.(&Rand, i16, i16)->i16 = if (preferences.inclusivity) rand.range_inclusive(i16) else rand.range_exclusive(i16);
  // implicit type is:
  // struct fn.(&Rand, i16, i16)->i16 {
  //   func: fn(&Rand, i16, i16)->i16,
  //   this: &Rand,
  // }
  range_func(-1000, 1000); // equivalent `range_func.func(range_func.this, -1000, 1000)`

  // the usual function pointer coercion rules apply for the `this` parameter:
  const maybe_const_this: fn.(&const Rand)->u32 = if (preferences.do_things) rand.next_unsafe else rand.const_pointer_this;

  // error: method signatures have to match:
  //const broken = if (preferences.do_things) rand.next_unsafe else rand.fill_array;

  // error: pointer and by-val this do not coerce
  //const what_is_this = if (preferences.do_things) rand.next_unsafe else rand.by_val_this;
}
@thejoshwolfe thejoshwolfe added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Apr 20, 2016
@andrewrk andrewrk added this to the 0.1.0 milestone Apr 20, 2016
@andrewrk
Copy link
Member

Is this still necessary given the new generic syntax?

const bound_next_func: fn.(&Rand)->u32 = if (preferences.safety) rand.next_safe else rand.next_unsafe;
bound_next_func(); // equivalent to `bound_next_func.func(bound_next_func.this)`

How about instead:

const nextFunc = if (preferences.safety) Rand.nextSafe else Rand.nextUnsafe;
nextFunc(rand);

@andrewrk andrewrk modified the milestones: 0.1.0, 1.0.0 Sep 26, 2016
@andrewrk andrewrk modified the milestones: 1.0.0, 0.2.0 Mar 26, 2017
@andrewrk andrewrk modified the milestones: 0.2.0, 0.3.0 Nov 14, 2017
@andrewrk andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018
@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Sep 28, 2018
@andrewrk andrewrk added proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. and removed enhancement Solving this issue will likely involve adding new logic or components to the codebase. labels Mar 14, 2019
@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 May 9, 2019
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Oct 17, 2019
@andrewrk
Copy link
Member

andrewrk commented Oct 9, 2020

The new plan is to get rid of the BoundFn type. I think this is possible now that we have @as instead of function calls. cc @SpexGuy

@andrewrk andrewrk closed this as completed Oct 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

2 participants