On Wednesday, 4 October 2023 at 21:03:14 UTC, bachmeier wrote:

I have never once said he cant talk about whatever he wants to, I've explicitly said the opposite. All I said is that by virtue of who he is has more interesting things to talk about than whether "enum { yes, no }" is a good idea or not.

Maybe we should hold people to lower standards the higher up they get and see how that works out?

On Thursday, 5 October 2023 at 00:53:45 UTC, claptrap wrote:

His point here was not that having an enum with values for yes and no is a bad idea. The bad idea is assigning yes the value 0.
That's a much more subtle point, as here nowhere 0 is written. That's what make this kind of mistakes so easy and I think it's well worth to explain it to less experienced programmers.

It's not easy to make simple looking code. That has nothing to do with (coding-)style, it is all about not defining things a different way than it is usually done, so nobody mix it up.
Sometimes it's very hard to find the correct order of things - often even experiments are necessary to determine what "usually" means.
What he says is: Invest your time to find out what "usually" means, and that is not trivial, even if it sounds like it is. It requires a lot of experience to come to this conclusion. Investing time to make things look easy and obvious is well worth it, despite you're likely not payed (or in your case: honored) for it.

On Thursday, 5 October 2023 at 08:46:50 UTC, Dom DiSc wrote:

His point was that both are bad, but one in worse.

And lets be honest, the problem is implicit casting of enums to int, and then to bool. Or the conflation of enums and manifest constants. If he wants to argue for self evident code then maybe that kind of thing needs looking at. Even the UFCS chain example is bad. Is...

a.b.c()

actually... "c(b(a))"

or is it member function b() on object 'a' that returns an object with member function c().

It's not self evident is it? So yes UFCS makes the "pipeline" easier to read, but it actually makes the code more ambiguous if you dont know what each of the things is. So you need more context to understand it.

If he was doing a talk to a bunch of inexperienced programmers then yes that stuff might be interesting, but he wasnt. You need to understand who your audience is, otherwise you risk wasting your and everyone elses time.

While I agree with the overall gist I didn't find his examples very interesting or convincing. They were pretty much all made up to illustrate, outdated, or disingenuous (the first one with the intentionally obfuscated code).

It would have been far better if he had actual real code examples he'd cleaned up.

I think if class is a reference type, it should've been explicit:

class C {
    ...
}

auto obj = new C();

void func(ref C obj)
{
    ...
}

I don't mind if it does not compile without the ref, but it should be on the table - WYSIWYG.

On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote:

Thanks, I think we need more of this as D has become a large language already.
There were some points I even never considered before.

I disagree however in all binary types should be just boolean.
I prefer machineState=State.On or State.Off than isMachineOn=true or false.

On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote:

I have another thing to add. You argued about reasons not to use macros but these reasons don't apply to AST Macros, they won't allow constructing new languages like in Lisp or in Neat.

Typed AST Macros would only accept parseable D source code with correct typing while untyped AST Macros would relax typing issues but syntax is still valid D.

On Sunday, 8 October 2023 at 13:21:12 UTC, sighoya wrote:

A good reference to compare are Scala Macros: https://docs.scala-lang.org/scala3/guides/macros/macros.html

Also Swift Macros: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/