January 15, 2019
On 2019-01-15 12:53, Walter Bright wrote:

> Template expressions can't, either, but what they do is hijack the syntax for completely different purposes. The poor reader will be looking at code, and it will behave nothing like the syntax suggests.

Ah, you mean like this:

struct MyInt
{
    private int value;

    MyInt add(MyInt other)
    {
        return MyInt(value - other.value);
    }
}

Perhaps we shouldn't support user defined types or functions either ;)

-- 
/Jacob Carlborg
January 15, 2019
On Tuesday, 15 January 2019 at 17:29:12 UTC, welkam wrote:
> On Tuesday, 15 January 2019 at 11:59:58 UTC, Atila Neves wrote:
>> He's not saying "kill classes in D", he's saying an OOP system in D could be implemented from primitives and classes don't need to be a language feature, similar to CLOS in Common Lisp.
>
> For some people writing OOP means writing keyword class.

I am not interested in OOP as a library feature rather then a built in feature. Let not repeat the same mistakes as c++. If there were a dip that involves deprecating class, expect me to be very vocal in regards to opposing it.
January 15, 2019
On 1/15/2019 10:39 AM, Jacob Carlborg wrote:
> Perhaps we shouldn't support user defined types or functions either ;)

You deliberately wrote that, and I'm confident you'd never try to pass that off as good work.

With macros, however, programmers are convinced they are creating models of clarity. I've seen programmers truly believe:

    #define BEGIN {
    #define END }

improves their C code. Fortunately, that was ridiculed out of existence in the 1980s, but the more subtle abuses persist with their ardent defenders. I used to use a lot of macros in my C code, and a few years back made an effort to remove them all from the dmd source code. The result was very satisfactory.

I've seen entire code bases abandoned because of macros after the original developer left.

January 16, 2019
On Wednesday, 16 January 2019 at 05:32:51 UTC, Walter Bright wrote:
> On 1/15/2019 10:39 AM, Jacob Carlborg wrote:
>> Perhaps we shouldn't support user defined types or functions either ;)
>
> You deliberately wrote that, and I'm confident you'd never try to pass that off as good work.
>
> With macros, however, programmers are convinced they are creating models of clarity. I've seen programmers truly believe:
>
>     #define BEGIN {
>     #define END }
>
> improves their C code. Fortunately, that was ridiculed out of existence in the 1980s, but the more subtle abuses persist with their ardent defenders. I used to use a lot of macros in my C code, and a few years back made an effort to remove them all from the dmd source code. The result was very satisfactory.
>
> I've seen entire code bases abandoned because of macros after the original developer left.

I'm pretty sure Jacob is talking about a completely different type of macro (i.e. not textual substitution), AST macros.
I'd be interested to see how close we could get if we allowed mixin template to contain expression as well as declarations (obviously these could only be instantiated in function contexts). Anyway something to play around with at DConf.
January 16, 2019
On 1/15/2019 11:08 PM, Nicholas Wilson wrote:
> I'm pretty sure Jacob is talking about a completely different type of macro (i.e. not textual substitution), AST macros.

I understand he means AST macros, but they aren't fundamentally different in the characteristic I'm talking about.



> I'd be interested to see how close we could get if we allowed mixin template to contain expression as well as declarations (obviously these could only be instantiated in function contexts). Anyway something to play around with at DConf.

I won't discourage you to play around with it, but I don't think it's what D needs in the near future.
January 16, 2019
On 1/15/2019 11:39 AM, 12345swordy wrote:
> If there were a dip that involves deprecating class,

I wouldn't worry about that getting very far :-)
January 16, 2019
On 2019-01-16 06:32, Walter Bright wrote:

> You deliberately wrote that, and I'm confident you'd never try to pass that off as good work.

Yes. I'm showing it's possible to write bad code in all programming languages with all (most) features. Macros are not required for that.

> With macros, however, programmers are convinced they are creating models of clarity. I've seen programmers truly believe:
> 
>      #define BEGIN {
>      #define END }
> 
> improves their C code. Fortunately, that was ridiculed out of existence in the 1980s, but the more subtle abuses persist with their ardent defenders. I used to use a lot of macros in my C code, and a few years back made an effort to remove them all from the dmd source code. The result was very satisfactory.
> 
> I've seen entire code bases abandoned because of macros after the original developer left.

D has done a great job of replacing the C preprocessor with alternative features. These include: "import", "debug" and "version". These features are great and don't need much improvement. They take care of the stuff that is really difficult to avoid the preprocessor in C for.

Then we have the other stuff: macros. To insert code at the instantiation point. For this, D has string mixins and template mixins. This is where D is lacking some features. For example, it's not possible to insert a symbol with a string mixin that the surrounding scope at the instantiation point cannot access. For example, you want to insert two symbols, but the surrounding code should only have access to one of the symbols, the other one is a helper symbol to the first one. This is not possible today. Unfortunately that doesn't stop anyone from trying to come up with there own workarounds and solutions, like generating some obfuscated symbol name. It's not gonna make it less accessible, just less likely to collide with an existing symbol.

It's also not possible to insert a symbol that refers to another symbol in another module without risking a symbol conflict in the local scope.

There's a word for this, mixins are not hygienic.

While D improves a lot on the C preprocessor it didn't reach all the way to cross the finish line.

-- 
/Jacob Carlborg
January 16, 2019
On 2019-01-16 08:08, Nicholas Wilson wrote:

> I'm pretty sure Jacob is talking about a completely different type of macro (i.e. not textual substitution), AST macros.

Yeah, I should come up with a new name than "macro". A soon as Walter sees the word "macro", regardless of its meaning in the context, he will throw his hands in the air and run the other way.

-- 
/Jacob Carlborg
January 16, 2019
On Monday, 14 January 2019 at 10:18:34 UTC, Martin Tschierschke wrote:
>
> This is exactly the argument to get a database driver (mysql,postgres...) and probably a webserver in std.

Absolutely not! Please...

IMHO, what needs to be in std are just APIs (modules, interfaces, declarations)...
Leave the implementations elsewhere please. Standard library is already too large for my taste!

What should be in std are just core stuff that is needed everywhere.

However, the REFERENCE IMPLEMENTATIONS of these APIs could be, and in fact SHOULD be, in a set of higher-level implementation libraries that should be developed by the D Foundation, and available on the dlang.org for downloads. (part of some kind of Standard Library Suite)
January 16, 2019
On Wednesday, 16 January 2019 at 11:35:15 UTC, Dejan Lekic wrote:
> On Monday, 14 January 2019 at 10:18:34 UTC, Martin Tschierschke wrote:
>>
>> This is exactly the argument to get a database driver (mysql,postgres...) and probably a webserver in std.
>
> Absolutely not! Please...
>
> IMHO, what needs to be in std are just APIs (modules, interfaces, declarations)...
> Leave the implementations elsewhere please. Standard library is already too large for my taste!
>
> What should be in std are just core stuff that is needed everywhere.

Depends on what you consider core stuff. I don't think webserver should be a part of the standard library, but I think stuff like sockets, XML and JSON should. Serialization? Debatable. Database driver? Maybe not specific backends, but there could be a generic driver interface.