On Tuesday, 12 July 2016 at 15:50:59 UTC, Ethan Watson wrote:
> that aren't necessarily up to date. What I'd rather do is have further examples visible online for C++17 standards to compare against. Either way, given Microsoft's rate, the industry will be able to use C++17 some time in 2021.

Well, just make sure you say you are aware of it ;-), or else you'll get the same response that you would get from D-users if you compared C++17 to D1...

I can get this to work:

  template<class, class = void_t<>> struct has_equality : std::false_type { };

  template<class T >
  struct has_equality<T, void_t<decltype(
     std::declval<T&>() == std::declval<T&>()
  )>> : std::true_type { };

and call it with:

  if( has_equality<int>() ) ...

with C++14 you also can get rid of the parens by binding ::value so you get

  if( has_equality<int> ) ...

> horrible to do in C++. SFINAE whackiness leads me in to talking about the is operator in D, which leads in to talking about the binding system... It's all about how it directly relates to usage, not to what someone can do in six years time.

I am not sure if I understand the argument. Wouldn't MS have kept D at D1 if the core issue is their backend? Why is it easier to user D than clang/gcc?

On Tuesday, 12 July 2016 at 16:24:07 UTC, Ola Fosheim Grøstad wrote:
>
>   template<class T >
>   struct has_equality<T, void_t<decltype(
>      std::declval<T&>() == std::declval<T&>()
>   )>> : std::true_type { };

It looks horrible.
And in D it is much prettier.

On Tuesday, 12 July 2016 at 16:24:07 UTC, Ola Fosheim Grøstad wrote:
> you'll get the same response that you would get from D-users if you compared C++17 to D1...

That's both wildly hyperbolic; and not going to happen for the mentioned reasons.

> I can get this to work:

Which is both not the way I'm currently doing it, and not the way I've seen it done elsewhere. Effectively, the way I've seen it done is by testing the return type of a variadic-template-parameterised function that is specialised with the decltype for the operation in question.

However, this goes to prove my point. In both cases, it's a bunch of legwork just to get to a true_type or a false_type. Having it available in the standard library ignores the fact that if you need to do something similar that will never be covered by the standards, it's a whole bunch of near-esoteric work you'll need to understand to get to that point.

Whereas in D, you can do the same thing with an is() statement.

As I pointed out at DConf (and which I saw someone around here quote somewhere), the number one thing you can do in D that you can't do in C++ is save time. The is() statement isn't just a simple operator, it's far more powerful that writing a boatload of boilerplate template code because it tests if code compiles. Far more flexible than writing template code for the fail case and specialising for the success case, far quicker to learn, far quicker to use, far quicker to write, etc.

> I am not sure if I understand the argument.

Did you see my DConf talk? Do you know that DMD uses mslink for 64 bit builds, and we use the Xbox One version of mslink to get Xbox One compatibility? It seems to me you'll understand where I'm coming from better if you look at what I've already put out there.

On Tuesday, 12 July 2016 at 17:55:22 UTC, Ethan Watson wrote:
> However, this goes to prove my point. In both cases, it's a bunch of legwork just to get to a true_type or a false_type.

Ok, I don't have much trouble with it. I usually want to abstract such tests into concepts and stuff them in to a library and only use "has_equality<T>"...


> covered by the standards, it's a whole bunch of near-esoteric work you'll need to understand to get to that point.

Well, the problem is that there is a lot of out-dated advice out there for how to do template programming in C++ that is rather convoluted. But there are some fairly simple patterns to use for both testing functionality and disabling functionality.

In my view the major advantage D has is in being able to disable struct fields with static if, I haven't found a simple way to do that in C++.


> Whereas in D, you can do the same thing with an is() statement.

Sure, you can always add special-cased builtins, but if you can express it in a relatively simple core inference engine then you can just add it with syntactical sugar and avoid all the special casing in analysis stages. Lowering to the core language should always be the preferred way to extend the language.

So from a language design perspective it is sound to only implement the core language and enable library solutions. If that leads to boiler plate you need to reconsider the abstraction mechanisms you provide and not necessarily add lots of special cased functionality.

The inference engine that C++ templates provide is convoluted, no doubt about it, but that is a past mistake. Adding special casing isn't the right answer to rectifying the mistake.

> Did you see my DConf talk? Do you know that DMD uses mslink for 64 bit builds, and we use the Xbox One version of mslink to get Xbox One compatibility? It seems to me you'll understand where I'm coming from better if you look at what I've already put out there.

I haven't seen any of the 2016 DConf talks.

On 2016-07-12 13:27, Ethan Watson wrote:
> http://schedule.gdceurope.com/session/d-using-an-emerging-language-in-quantum-break
>
>
> My proposal for a talk has been accepted, and I'll be in Cologne next
> month presenting to industry peers.

Will the talk be recorded?

-- 
/Jacob Carlborg

On Tuesday, 12 July 2016 at 11:27:18 UTC, Ethan Watson wrote:
> http://schedule.gdceurope.com/session/d-using-an-emerging-language-in-quantum-break
>
> My proposal for a talk has been accepted, and I'll be in Cologne next month presenting to industry peers.
>

Awesome ! I hope you can make good impression.

On Tuesday, 12 July 2016 at 11:27:18 UTC, Ethan Watson wrote:
> http://schedule.gdceurope.com/session/d-using-an-emerging-language-in-quantum-break
>
> My proposal for a talk has been accepted, and I'll be in Cologne next month presenting to industry peers.
> ....
> ....
> Speaking of the binding system, the plan is to open source it for the talk. I'm in the process of cleaning it up right now for such purposes.

Cool, the full presentation will be in the GDC Vault afterwards I guess for people who can't attend.

It feels like some of the "code as data" aspects you are covering in your DConf presentation are similar to mono based frameworks implementations that mainly use C#. So I would focus on C# too as it is a very familiar language in a lot of large game productions. We actually  have a couple of domain specific languages that are very close to C# but compile to C++.

On Tuesday, 12 July 2016 at 11:27:18 UTC, Ethan Watson wrote:
> http://schedule.gdceurope.com/session/d-using-an-emerging-language-in-quantum-break
>
> My proposal for a talk has been accepted, and I'll be in Cologne next month presenting to industry peers.
>
> One of the things I was asking during the approval process was whether attendees tended to be more on the game programming side or the tech/engine programming side. They don't have that data. Looking at the rest of the talks on the schedule, there does appear to be a bit of a lack of technical talks. So that pretty much settles it for me, I'm going to go a bit in-depth on D. I've been seeing this talk as basically a sales pitch to the rest of the industry to check D out, and going in-depth means its time to shine.
>
> The general gist of the talk will broadly cover what both my talk at DConf this year and Manu's talk at DConf in 2013 covered. But to break up the flow a bit, I intend on inserting examples of ways D saves time. Take the lighting talk I did about a simple interpolation function - illustrate the problem in C++, and the solution in D. But because there's options out there for languages these days, I also want equivalent solutions in Rust (as that is the most likely other option). I might also add a column for Swift so I can write "LOLNO" for each problem. Perhaps also relevant is C# equivalents as that has quite a lot of support in game programming these days thanks to Unity.
>
> The examples are also meant to highlight specific language features. The interpolation example highlights template constraints and type inspection. And they're going to be based on code I've either written for Quantum Break, or had to spend an unholy amount of time getting to work in C++ recently.
>
> Mainly here, I would like the assistance of someone that has used Rust and can provide Rust-based examples that perform the same task. Stefan Koch was also illustrating some of the modern syntactic shortcuts on IRC last night, I've been programming in a DMD that was released in 2013 for a while so getting up to speed on modern D programming with my examples will help make this even tighter than I can otherwise make it by myself.
>
> The examples I'm looking at using (aiming for a spacing of about one every 10-15 minutes in the talk, so 4 in total):
>
> * Generic interpolation function
>   - Already illustrated at DConf for both C++ and D
>   - C++ - Unmaintainable, buggy mess
>   - Rust - No idea
>   - D - Write once, handle any type thanks to type inspection
>   - D feature demonstration: template constraints, type inspection
>
> * Check a type for an equality operator
>   - C++ - SFINAE whackiness, and as near as I can tell requires separate tests to determine if an object has a member operator and/or a global operator for comparison tests
>   - Rust - No idea
>   - D - Simple is() check wrapped in an enum
>   - D feature demonstration: is, static if for further use
>
> * Expansion of code for a script wrapper to a native function (retrieve parameters and pass to native)
>   - C++ - Pre-C++11 is a mess but doable. Will focus on C++11, which requires template parameter inference, compile time number range generation, and calling a function with two dummy instances of objects to allow the inference to happen.
>   - Rust - No idea
>   - D - Haven't written the code, but intend on using mixin with strings
>   - D feature demonstration - mixin, mixin template
>
> * Fourth example TBD, might try to make it tie in to the binding system which means I'll cover CTFE.
>
> Speaking of the binding system, the plan is to open source it for the talk. I'm in the process of cleaning it up right now for such purposes.

Just saw this on Gamasutra:

http://www.gamasutra.com/view/news/278892/Catch_these_great_talks_at_GDC_Europe__Online_registration_closes_Wednesday.php

"Plus, there'll be an excellent talk from Remedy Entertainment's Ethan Watson about how the studio built its hit 2016 action game Quantum Break using the D programming language.

"D: Using An Emerging Language in Quantum Break" is a notable talk about a language that's rarely discussed in game development, and Watson aims to answer important questions like: what benefits does D have over C++? Is it ready for mass use? Does treating code as data with a traditional C++ engine work?

His talk will cover Remedy's usage of the D programming language in Quantum Break and also provide some details on where the studio wants to take usage of it in the future. Make sure to check it out if you're interested in gaining knowledge of a realistic alternative to C++, an understanding of D's real world usage and insight into what the possibilities could be for your own usage."

Good luck with the talk, Ethan. Looks like this will provide a lot of visibility for D.