On Thursday, 23 May 2019 at 13:01:58 UTC, Atila Neves wrote:

> If the linker does its job, does it matter that individual object files are larger?

Yes, my understanding is that the final binary would only have a single copy of whatever templates were instantiated.  However, there is a danger for template bloat if their are too many template permutations based on type or other compile-time factor.  For example, if the authors of druntime create large functions templated on type without factoring out the type-independent code into smaller functions.  Then template bloat could become a problem.  It's just something that needs to be carefully monitored if everything in the runtime is to be a template.

Mike

On 5/23/19 5:46 AM, Timo Sintonen wrote:
> On Thursday, 23 May 2019 at 06:41:04 UTC, Mike Franklin wrote:
> 
>>> Oh, and druntime must go.
>>>
>>> The whole distinction between the runtime library and the standard library is clowny and has more to do with poorly ported tradition from other languages, than with anything else.
>>>
>>> We need one standard library that is entirely pay-as-you-go (e.g. empty main() means no library file is ever needed for linking) and that offers an opt-in continuum.
>> ---
>>
>> So, the divide between druntime and phobos shouldn't even exist.  But what does a united druntime/Phobos look like?  How do we organize it logically, and modularly with clear boundaries, so it doesn't turn into a tangled mess and users only pay for what they use?  I don't know, but I'm trying to figure that out.
>>
> 
> We actually do need a runtime library. It should contain code for compiler generated runtime function calls. Nothing else.

Ideally all of those would be small function templates.

On Thursday, May 23, 2019 1:45:23 AM MDT Seb via Digitalmars-d wrote:
> On Thursday, 23 May 2019 at 07:40:20 UTC, Mike Franklin wrote:
> > On Thursday, 23 May 2019 at 07:26:34 UTC, Mike Franklin wrote:
> >> On Thursday, 23 May 2019 at 07:17:19 UTC, Manu wrote:
> >>> So, std.range.primitives -> core.range ?
> >>
> >> Take your best guess, submit a PR and see what the reviewers say.
> >>
> >>  If I had to make a decision, I'd just mimic what's in Phobos
> >>
> >> (i.e. replace `std` with `core`), unless there's a good reason
> >> not to.
> >
> > A more conservative approach would be to put them in `core.internal`.  `core.internal.traits` is already there.  My understanding is that anything in `core.internal` is not intended for public consumption, so we could start there without committing to a public interface that we'd have to maintain.  It can always be exposed publicly later when the future becomes more clear.
> >
> > Mike
>
> Yes, let's go with core.internal.range.
>
> Motivation: when we can the package name, we have the unique opportunity of getting rid of some historic range missteps like auto-decoding for strings or using a special save() constructor for ForwardRanges to support class ranges.

Anything along those lines that gets done in druntime at this point needs to not be part of the public API, because if we're really going to do some kind of phobos v2 and fix some of the mistakes with ranges, we want to get it right. And if we have something in core which is public, that will get in the way of that. Either way, it won't work to copy what we have in std.range.primitives right now (at least not for strings), because that relies on std.utf. However, since actually redesigning ranges is a much larger discussion, it really wouldn't be appropriate to just throw a new API in druntime either. So, I don't know that it's appropriate to put much in the way of range stuff in druntime at the moment. Not much there should even need it either. Regardless, anything that is done needs to be completely internal for now.

- Jonathan M Davis