ref ubyte[n*2] requires_ptr_twice_as_large_as_input(uint n)
    (
        const ref ubyte[n] input,
        ref ubyte[n*2] output,
    ) {
        output[0..n] = input[0..n];
        output[n..2*n] = input[0..n];
        return output;
    }

    void main()
    {
        ubyte[10] input = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
        ubyte[20] output;
        requires_ptr_twice_as_large_as_input!(10)(input, output);

        import std.stdio;
        writeln(output);
        assert(output == input ~ input);
    }

  import std.sumtype;
  
  void main(){
   struct A { int a; }
   struct B { string b; }
   struct C { bool c; }
   
   alias TaggedUnion = SumType!(A, B, C);
   
   auto tgu = TaggedUnion(B("hi"));
   int i = tgu.match!(
    (A a) => a.a,
    (B b) => b.b.length,
    (C c) => c.c * 5
   );
   assert(i == 2);
  }

I know of sumtype, and i think it is a mistake for D to rely on this for such important language feature

I'm not a language dev, so i can't do much to help, using switch/union/enum is more natural, is cleaner, and is easier to add support for IDEs, everyone on the same page

That's in areas like this where the language falls short, and i can see people instead choosing alternatives

https://github.com/dlang/phobos/blob/master/std/sumtype.d

a mess of templates and imports to std.traits

using this will make your compile speed tank.. another reason to avoid

it's very sad that people recommend this instead of asking for built-in version, makes me sometimes reconsider my choice to use the language

if they expect language improvements to be templates, what atrocity will be added next?

this is on the same level as std::bool from C++

> The good news is, I have not put a lot of effort so far into micro-optimizing the compile-time performance of match, so there is almost certainly room for improvement.

it is shame that it ended up in the standard library

once Walter will be gone, i will have no faith in the language anymore

  scope obj = new Object;
  ...
  // destroyed at end of scope

No generics actually harms code clarity and destroys type safety.

The official stance on that issue is: yeah, but it's better than the hassle of supporting generics (compiler effort, object code size/slowness, and excessive high-level abstraction (a bad thing in the Go world).

I have a foot on both sides: I miss generics when I'm writing one-off low-scalability code, but it's nice to have the speed of low-level Go code, and perversely fun to actually spend some of my coding time writing all those low-level sorting and array-building routines that are the meat of programmer interviews.

Now, when a candidate asks "When will I need to write a method to sort the keys of a map?", I can answer "Every time you use a map[string]T for a novel T!"

I hate novel T now. (<-- This is also a design feature of Go, the passive pressure to not use large hierarchical types, and try to do your work with just maps and slices of primitives)

It's actually clearer as to what's going on since slices are a language primitive. They are simple and extremely transparent. This is absolutely not the case with Java's collections library or the C++ STL.

It wouldn't be a trade-off if there weren't situations where generics are really useful. But this rings more like an armchair criticism of Go than a criticism from someone who's written some Go programs. For my part, I wish languages like Java were less hostile to arrays.

If this is 'armchair criticism' why do Go's designers say they are considering adding generics support?

There are tons of other interesting uses for macros. Obviously I'd rather a language had safer equivalents to a C preprocessor.

D's template support is far superior: static if, constraints, compile-time function execution, string mixins, opDispatch. These features make templates much more practical and more powerful.

And your sharp looking clothes are far more wasteful than a peasant shirt and plain shorts.

And your smart phone is far more wasteful than a basic phone.

And a house with a yard is vastly more wasteful than a 150 sqft per person apartment.

And do you know how much wastage occurred to make that movie you watched? Or that TV show you like?

Everything can be considered wasteful by comparison. It comes down to balancing your needs/wants with energy requirements, and choosing which causes to bring up when preaching your moral superiority.

But regardless, this is what I mean by choosing which causes to bring up when preaching your moral superiority.

The level of meat consumption in rich countries is unjustifiable.