[Design Question] Metaprogramming as a non-goal

Evolution Discussion
1

In the swift/docs/Generics.rst documentation, I see:

"
As important as the goals of a feature are the explicit non-goals, which we
don't want
or don't need to support:
* Compile-time "metaprogramming" in any form
* Expression-template tricks a la Boost.Spirit, POOMA
"

What kinds of things count as compile-time metaprogramming? I've been
tinkering with some ideas related to the type system and having a more
specific description here might help me pare many / most / all of them down.

Mike

2

I'd guess the point is that the generics system isn't meant to force the
compiler to perform the sorts of things C++'s (Turing-complete) template
system can:

    template<size_t... F>
    struct Fibonacci { };

    // API
    template<size_t n>
    struct Fibonacci<n> {
        static constexpr size_t value = Fibonacci<n, 1, 0>::value;
    };

    // Recursive implementation
    template<size_t n, size_t Fn, size_t Fm>
    struct Fibonacci<n, Fn, Fm> {
        static constexpr size_t value = Fibonacci<n-1, Fn+Fm, Fn>::value;
    };

    // Base case
    template<size_t Fn, size_t Fm>
    struct Fibonacci<0, Fn, Fm> {
        static constexpr size_t value = Fn;
    };

    int main() {
        printf("F(200): %zu\n", Fibonacci<200>::value);
        return 0;
    }

Jacob

···

On Sat, Jan 23, 2016 at 11:17 PM, Michael Henson via swift-evolution < swift-evolution@swift.org> wrote:

In the swift/docs/Generics.rst documentation, I see:

"
As important as the goals of a feature are the explicit non-goals, which
we don't want
or don't need to support:
* Compile-time "metaprogramming" in any form
* Expression-template tricks a la Boost.Spirit, POOMA
"

What kinds of things count as compile-time metaprogramming? I've been
tinkering with some ideas related to the type system and having a more
specific description here might help me pare many / most / all of them down.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Some of us suspect that the generics model we already have would offer
this capability, if it weren't for bugs in the implementation:

  protocol BooleanType {}

  struct False : BooleanType {}
  struct True : BooleanType {}

  protocol IfType {
    typealias C : BooleanType
    typealias T
    typealias F
    typealias Result = F

    var result: Result? {get}
  }

  extension IfType {
    var result: Result? { return nil }
  }

  // Take this extension away to change the result
  extension IfType where Self.C == True {
    var result: T? { return nil }
  }

  struct If<C_: BooleanType, T_, F_> : IfType {
    typealias C = C_
    typealias T = T_
    typealias F = F_
  }

  print(If<True, Int, String>.Result.self) // prints Int; OK
  print(If<False, Int, String>.Result.self) // prints Int; should print String

But, basically, that part is saying we would prefer it if ideas like
this were expressed directly (e.g. by an actual "if" statement used with
a macro system) rather than by hijacking features of generics.

HTH,

···

on Sat Jan 23 2016, Michael Henson <swift-evolution@swift.org> wrote:

In the swift/docs/Generics.rst documentation, I see:

"
As important as the goals of a feature are the explicit non-goals, which we
don't want
or don't need to support:
* Compile-time "metaprogramming" in any form
* Expression-template tricks a la Boost.Spirit, POOMA
"

What kinds of things count as compile-time metaprogramming? I've been
tinkering with some ideas related to the type system and having a more
specific description here might help me pare many / most / all of them
down.

--
-Dave

4

Unfortunately that’s exactly what would make a library with typed units possible (see thread about „Epic: Typesafe calculations“).

-Thorsten

···

Am 24.01.2016 um 10:01 schrieb Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org>:

I'd guess the point is that the generics system isn't meant to force the compiler to perform the sorts of things C++'s (Turing-complete) template system can:

    template<size_t... F>
    struct Fibonacci { };

    // API
    template<size_t n>
    struct Fibonacci<n> {
        static constexpr size_t value = Fibonacci<n, 1, 0>::value;
    };

    // Recursive implementation
    template<size_t n, size_t Fn, size_t Fm>
    struct Fibonacci<n, Fn, Fm> {
        static constexpr size_t value = Fibonacci<n-1, Fn+Fm, Fn>::value;
    };

    // Base case
    template<size_t Fn, size_t Fm>
    struct Fibonacci<0, Fn, Fm> {
        static constexpr size_t value = Fn;
    };

    int main() {
        printf("F(200): %zu\n", Fibonacci<200>::value);
        return 0;
    }

Jacob

On Sat, Jan 23, 2016 at 11:17 PM, Michael Henson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
In the swift/docs/Generics.rst documentation, I see:

"
As important as the goals of a feature are the explicit non-goals, which we don't want
or don't need to support:
* Compile-time "metaprogramming" in any form
* Expression-template tricks a la Boost.Spirit, POOMA
"

What kinds of things count as compile-time metaprogramming? I've been tinkering with some ideas related to the type system and having a more specific description here might help me pare many / most / all of them down.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution