On Mon, Jan 14, 2019 at 03:57:36PM +0000, Adam D. Ruppe via Digitalmars-d-announce wrote:
> On Monday, 14 January 2019 at 14:56:00 UTC, bachmeier wrote:
> > Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage.
> 
> Real D is the true better C. These improvements can improve in various situations.
> 
> That said though, I'd be against removing built-in classes and interfaces.  They are useful in a lot of places built in...

Yeah, much as I'm a big promoter of struct-based range-based template style D code, classes and interfaces do still have their place.  When you need runtime dynamic polymorphism, it just makes sense to use classes and interfaces instead of trying to bandage your way around structs and CT introspection.  I'm still searching for a theoretical model that would bridge the gap between the two and make one unified model, but for now, they each still have their place.


> though I kinda wish the runtime code was a bit thinner and lighter too.

Yeah, the whole thing about the monitor field IMO is an unnecessary burden on a use case that isn't always needed.  If synchronized classes or whatever needs it, then it should be an ABI specific to synchronized classes.  Everybody else shouldn't need to pay tax on it if they never actually need to use it.


T

-- 
Shin: (n.) A device for finding furniture in the dark.

On 2019-01-14 08:50, Walter Bright wrote:

> Interesting cites, which provide a basis for why I've opposed AST macros, and why Ddoc and unittest are builtin (and a few other things).

But Ddoc has macros ;)

-- 
/Jacob Carlborg

On 2019-01-14 15:42, Steven Schveighoffer wrote:

> That's a bad example :) The clear answer is mysql-native, which is what vibe.d recommends.

Exactly, and I don't need five minutes for that. Five seconds is enough :)

-- 
/Jacob Carlborg

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0
>
> If nothing else please watch the opening story, it's true and quite funny :o).
>
> Now as to the talk, as you could imagine, it touches on another language as well...
>
>
> Andrei

About the adoption and success of DbI libraries:

- Buried inside your talks there are lots of hard-earned principles:
  "What's missing is as important as what's here"
  "Big interfaces are good"
  etc...
  We have a lack of DbI designers such as yourself or Vladimir so a short text that teach how to design with DbI could be in order.
  I redirect people to "std::allocator is to allocation what std::vector is to vexation" because it seems to be the only tutorial on this.

  Other people often lack interest because of real or perceived template bloat, and it's critical.

- I think it's important to emphasize CTFE over template instantiations because (per Stefan's measurements) template instantiations are a lot slower and CTFE is already surprisingly faster than template meta-programming, and on the road to become even faster with the superbly needed newCTFE.

On Mon, Jan 14, 2019 at 08:38:39PM +0000, Guillaume Piolat via Digitalmars-d-announce wrote: [...]
> Other people often lack interest because of real or perceived template bloat, and it's critical.
> 
> - I think it's important to emphasize CTFE over template instantiations because (per Stefan's measurements) template instantiations are a lot slower and CTFE is already surprisingly faster than template meta-programming, and on the road to become even faster with the superbly needed newCTFE.

I think another angle of attack that AFAICT has been mostly overlooked is for the compiler to recognize certain common template patterns, and optimize away intermediate template instantiations that are not actually necessary.  Not every template instantiation requires wholesale copying of the AST.  I surmise certain patterns of templates could be profitably turned into some kind of compile-time executed code.


T

-- 
Без труда не выловишь и рыбку из пруда.

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0
>
> If nothing else please watch the opening story, it's true and quite funny :o).
>
> Now as to the talk, as you could imagine, it touches on another language as well...
>
>
> Andrei

A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook.

It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc.  One each for the required and optional methods.

The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately.

Is it possible to declare a function whose name is a CTFE computed string?

On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote:
> Is it possible to declare a function whose name is a CTFE computed string?

Yes, if you do it with a string mixin.

On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote:
> On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
>> https://youtube.com/watch?v=tcyb1lpEHm0
>>
>> If nothing else please watch the opening story, it's true and quite funny :o).
>>
>> Now as to the talk, as you could imagine, it touches on another language as well...
>>
>>
>> Andrei
>
> A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook.
>
> It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc.  One each for the required and optional methods.
>
> The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately.
>
> Is it possible to declare a function whose name is a CTFE computed string?

For ranges there are concepts like Input Range. A struct/class must have several methods to be compliant. You can check the compliance using function isInputRange
 https://dlang.org/library/std/range/primitives/is_input_range.html

Maybe something similiar can be done here. Not checking individual methods, but concepts...

Kind regards
Andre

On Monday, 14 January 2019 at 21:22:32 UTC, Andre Pany wrote:
> On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote:
>> On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
>>> https://youtube.com/watch?v=tcyb1lpEHm0
>>>
>>> If nothing else please watch the opening story, it's true and quite funny :o).
>>>
>>> Now as to the talk, as you could imagine, it touches on another language as well...
>>>
>>>
>>> Andrei
>>
>> A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook.
>>
>> It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc.  One each for the required and optional methods.
>>
>> The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately.
>>
>> Is it possible to declare a function whose name is a CTFE computed string?
>
> For ranges there are concepts like Input Range. A struct/class must have several methods to be compliant. You can check the compliance using function isInputRange
>  https://dlang.org/library/std/range/primitives/is_input_range.html
>
> Maybe something similiar can be done here. Not checking individual methods, but concepts...
>
> Kind regards
> Andre

I don't think that's quite sufficient because a hook may/may not have the optional methods, and could have extra stuff.  What you want is to specify per method "this method is part of the hook interface," which as I type it kind of sounds like the job of an annotation...

On 1/14/2019 10:49 AM, Jacob Carlborg wrote:
> But Ddoc has macros ;)

Indeed it does. But the macros cannot be used to create syntax, and there is no token concatenation. Macros cannot define other macros.