--- Comment #7 from Kenji Hara <> 2012-07-30 10:04:28 PDT ---
Module level template struct *is inferred* whether it's really nested or not.

struct Map(alias pred, Range) {
  Range input;
  this(Range r) { input = r; }
  @property empty(){ return input.empty; }
  @property front(){ return pred(input.front); }
  void popFront() { input.popFront(); }
auto map(alias pred, Range)(Range r) { return Map!(pred, Range)(r); }

void main() {
  int n = 2;
         int addN(int x) { return x + n; }
  static int add1(int x) { return x + 1; }

  auto r1 = map!addN([1,2,3]);
  // typeof(r1) is a nested struct, because pred has a frame pointer(FP).

  auto r2 = map!add1([1,2,3]);
  // typeof(r2) is not a nested struct, because pred doesn't have a FP.

But nested struct (declared in function body) cannot receive such treatment.

auto mapN(alias pred, Range)(Range r) {
  struct MapN { ... same as above Map ... }
  // MapN have always a FP, then if pred has another one, they conflict.

auto mapS(alias pred, Range)(Range r) {
  static struct MapS { ... same as above Map ... }
  // MapS cannot have any FP, then if pred has a FP, MapS cannot access it.

My proposal is:

auto mapTS(alias pred, Range)(Range r) {
  static struct MapTS(alias pred) { ... same as above Map ... }
  // MapTS can infer its actual nest-ness based on the pred2, as like Map.
  // But MapTS cannot access mapTS function's FP, because it's static struct.

(In reply to comment #4)
> I'm a bit confused by the example because it uses the symbol "pred" twice.
> Kenji, could you please change?

To ignite such nest-ness inference for MapTS, mapTS should pass the pred to
inner struct.


But, maybe, this proposal is a little complicated than the rule that you think
in your head. We might be able to be simplify the rule.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to