September 15, 2021
On Wednesday, 15 September 2021 at 11:43:19 UTC, Paulo Pinto wrote:
>
> Why is TLS out of question, when it is a standard C11 feature?

TLS doesn't play well with embedded systems. TLS is an OS related feature and not all OS:es support TLS among the small embedded ones. In general, we should avoid TLS as much we can because it's horrible under the hood.

Many languages support TLS including C++ and Rust. It's there to give the programmer the opportunity to use it.
September 15, 2021

On Tuesday, 14 September 2021 at 18:03:32 UTC, Kenneth Dallmann wrote:

>

There might be some potholes in the design of D. I think if I were to design
something like D I would follow Rust's example for memory management, and then
add in GC as an optional feature.

One of the advantages of GC is the expressiveness of the language.

See this:

T[] sorted(T)(T[] xs)
{
  return xs.length == 0 ? [] :
    xs[1..$].filter!(x=> x < xs[0]).array.sorted ~
    xs[0..1] ~
    xs[1..$].filter!(x=> x >= xs[0]).array.sorted;
}
void main()
{
    [ 3, 1, 2, 4, 0 ].sorted.writeln;
}

You simply can't write this kind of "one expression" syntax with Rust... If you try, you still end up with a mental sprain:

fn sorted(xs:Vec<f64>)->Vec<f64> {
    return match xs.len() {
        0 => Vec::<f64>::new(),
        _ =>
            sorted( xs[1..].iter().filter(|&x|x<=&xs[0]).map(|&x|x).collect() ).iter().
            chain( iter::once(&xs[0]) ).
            chain( sorted( xs[1..].iter().filter(|&x|x>&xs[0]).map(|&x|x).collect() ).iter() ).
            map(|&x|x).collect(),
    }
}

D expressiveness is great... Rust has not this capability

September 15, 2021

On Wednesday, 15 September 2021 at 15:51:11 UTC, Antonio wrote:

>

On Tuesday, 14 September 2021 at 18:03:32 UTC, Kenneth Dallmann wrote:

>

[...]

One of the advantages of GC is the expressiveness of the language.

[...]

Agreed. If D could get squeeze out those last 10% I would love to use it at work. Also adoption has to increase so the ecosystem can flourish

September 15, 2021
On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright wrote:
> GC already is an optional feature in D.

If only the standard library helped make this easier to work with.

We have the half-dead std.experimental.allocator, but no standard collections or lifetime containers.

D can shout that the GC is optional, and whilst true, it's only half the story.

I'm not even a GC-phobic, but I still see issues here.
September 15, 2021
On Wednesday, 15 September 2021 at 18:55:01 UTC, SealabJaster wrote:
> We have the half-dead std.experimental.allocator, but no standard collections or lifetime containers.

* based around allocators.



September 15, 2021
On Wednesday, 15 September 2021 at 18:55:01 UTC, SealabJaster wrote:
> On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright wrote:
>> GC already is an optional feature in D.
>
> If only the standard library helped make this easier to work with.
>
> We have the half-dead std.experimental.allocator, but no standard collections or lifetime containers.
>
> D can shout that the GC is optional, and whilst true, it's only half the story.
>
> I'm not even a GC-phobic, but I still see issues here.

C doesn't have a GC, can use libc, and nobody complain

D can do the same, so why complain? has full access to both libc and C libraries, you get  safeties and modern features on top of that

GC is optional, i use D myself without the GC most of the time

When memory management doesn't matter, i'm happy that it has the GC

Saying GC is not optional is plain and simple not true

D is the perfect tool because it adapts to the problem you want to solve

Want to do system level programming, it got you covered

Want to do scripting? it got you covered

Want to do a mix of the two? it gove you covered too



September 16, 2021
On Wednesday, 15 September 2021 at 14:48:56 UTC, IGotD- wrote:
>
> TLS doesn't play well with embedded systems. TLS is an OS related feature and not all OS:es support TLS among the small embedded ones. In general, we should avoid TLS as much we can because it's horrible under the hood.
>

To emulate TLS allocate a block of memory at the top/bottom of your stack and use a bitmask on your stack pointer in order to access it. No OS support required.
September 16, 2021
On Thursday, 16 September 2021 at 05:59:57 UTC, Araq wrote:
> To emulate TLS allocate a block of memory at the top/bottom of your stack and use a bitmask on your stack pointer in order to access it. No OS support required.

This can be pretty fast and portable, but there are some additional challenges with separate compilation.

Without separate compilation, you can generate constant offsets into the TLS area at compile time; with separate compilation, you either need to somehow bake this into the linking step or figure out offsets at runtime.

Likewise for the stack size, which must be consistent across all separately compiled modules.

But even with those constraints, it can still be a pretty good option.
September 16, 2021
On Thursday, 16 September 2021 at 05:59:57 UTC, Araq wrote:
>
> To emulate TLS allocate a block of memory at the top/bottom of your stack and use a bitmask on your stack pointer in order to access it. No OS support required.

The TLS standard requires the OS to initialize the TLS area for each new thread so OS support is required. You have size constraints when you put TLS on the stack. If some bright programmer decides to have several megabytes of data as TLS, this is not an option but this is a fringe case though. If your OS supports shared libraries, the implementation becomes much more complicated.

The C++ standard doesn't support contructors/deconstuctors in the TLS area, only simple zero and copy initialization is supported. D makes this more complicated as it supports contructors/deconstuctors in TLS. Because of this TLS increases the time for spawning new threads, especially in D and this regardless if the thread use any TLS variable or not.

If you have a single thread program, you can use the GCC TLS emulation.

The TLS standard feels rushed and shoved in with a shoehorn. There are several fringe cases to deal with.
September 16, 2021
On Thursday, 16 September 2021 at 10:04:22 UTC, IGotD- wrote:
> On Thursday, 16 September 2021 at 05:59:57 UTC, Araq wrote:
>> [...]
>
> The TLS standard requires the OS to initialize the TLS area for each new thread so OS support is required. You have size constraints when you put TLS on the stack. If some bright programmer decides to have several megabytes of data as TLS, this is not an option but this is a fringe case though. If your OS supports shared libraries, the implementation becomes much more complicated.
>
> [...]

What TLS standard?

POSIX, C11, C++11, Java, .NET, Win32 are the only standards that come to my mind where some kind of TLS is included, and naturally all of them have different semantics.