November 20, 2021
On 20/11/2021 6:13 PM, tsbockman wrote:
> 2) To specify APIs independent of implementation, for `extern` linking, `interface`s and base `class`es with multiple implementations that might imply different attributes, etc.

Indeed, there is no way around that. The compiler can emit them for .di files though.

> Attribute soup is unavoidable for (2) public APIs in general; there is nowhere else the information *can* come from in many cases except from an explicit specification, regardless of how sophisticated the compiler is.
> 
> Redundant specification of attributes for (1) verification purposes could be dropped, but I'd rather not since I find the compiler frequently catches mistakes or fuzzy thinking on my part by comparing explicit attributes to inferred.

If it works for you, go for it.

But this approach does not make memory safety easy. It makes it harder for the majority of people and that is the problem.
November 19, 2021
On 11/16/2021 1:00 PM, Robert Schadek wrote:
> GitHub has >10^7 accounts, D's bugzilla has what, 10^3?
> No matter what feature github is missing there is no reason to not migrate to
> github.

Sebastian wanted to do this, and we already gave him the go-ahead on it a couple years ago.
November 20, 2021

On Saturday, 20 November 2021 at 05:51:17 UTC, rikki cattermole wrote:

>

But this approach does not make memory safety easy. It makes it harder for the majority of people and that is the problem.

It is not only about harder, it is also about not having clutter. When people can choose between system development language 1 and 2... clutter matters.

November 20, 2021
On Saturday, 20 November 2021 at 07:07:55 UTC, Walter Bright wrote:
> On 11/16/2021 1:00 PM, Robert Schadek wrote:
>> GitHub has >10^7 accounts, D's bugzilla has what, 10^3?
>> No matter what feature github is missing there is no reason to not migrate to
>> github.
>
> Sebastian wanted to do this, and we already gave him the go-ahead on it a couple years ago.

You mean Wilzbach, not Koppe? Yes I realize Sebastiaan Koppe is two a's in the name but it's so easy to mess those up that it's hard to be sure without the surname.
November 20, 2021
On Saturday, 20 November 2021 at 07:07:55 UTC, Walter Bright wrote:
> Sebastian wanted to do this, and we already gave him the go-ahead on it a couple years ago.

I saw that and the discussion degenerated https://github.com/dlang/projects/issues/43 and then nobody took charge.
November 20, 2021
On Saturday, 20 November 2021 at 15:32:08 UTC, Dukc wrote:
> On Saturday, 20 November 2021 at 07:07:55 UTC, Walter Bright wrote:
>> Sebastian wanted to do this, and we already gave him the go-ahead on it a couple years ago.
>
> You mean Wilzbach, not Koppe? Yes I realize Sebastiaan Koppe is two a's in the name but it's so easy to mess those up that it's hard to be sure without the surname.

Ha, even for us :)
November 20, 2021
On 11/20/2021 7:34 AM, Robert Schadek wrote:
> On Saturday, 20 November 2021 at 07:07:55 UTC, Walter Bright wrote:
>> Sebastian wanted to do this, and we already gave him the go-ahead on it a couple years ago.
> 
> I saw that and the discussion degenerated https://github.com/dlang/projects/issues/43 and then nobody took charge.


You're right, it needs someone to take charge and keep hammering on it.
November 20, 2021
I'm looking it two right now.

The migration tool is not that great IMO, and this is a nice side project during dconf.

But to reiterate my point, I don't think this is an argument about the features of the tool but a social/visibility/ease of entry issue.

If I have something I'll post.


November 22, 2021

On Friday, 19 November 2021 at 19:41:59 UTC, Paulo Pinto wrote:

>

On Friday, 19 November 2021 at 19:02:45 UTC, Araq wrote:

>

On Friday, 19 November 2021 at 17:41:23 UTC, Paulo Pinto wrote:

>

On Friday, 19 November 2021 at 15:46:15 UTC, Tejas wrote:

>

On Friday, 19 November 2021 at 15:37:04 UTC, Paulo Pinto wrote:

>

[...]

What do you think about Nim's ARC + GC solution? They call it ORC :
https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html

It is an old idea that goes back to systems like Mesa/Cedar in the early 1980's.

https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837

Used to create this workstation OS at Xerox PARC,

https://m.youtube.com/watch?v=z_dt7NG38V4

Mesa/Cedar used deferred reference counting plus a cycle collector, that's Nim's old default GC, ORC is completely different... But hey, what do I know, I only implemented both.

Different in what way, given the optimizations referred in the paper and plans for future work, which unfortunately never realised given the team's move into Olivetti, where they eventually created Modula-2+ and Modula-3.

ORC is precise, it doesn't do conservative stack marking, ORC's cycle detector uses "trial deletion", not "mark and sweep", ORC removes cycle candidates in O(1) which means it can exploit acyclic structures at runtime better than previous algorithms, ORC has a heuristic for "bulk cycle detection"...

November 22, 2021

On Monday, 22 November 2021 at 10:16:28 UTC, Araq wrote:

>

On Friday, 19 November 2021 at 19:41:59 UTC, Paulo Pinto wrote:

>

On Friday, 19 November 2021 at 19:02:45 UTC, Araq wrote:

>

[...]

Different in what way, given the optimizations referred in the paper and plans for future work, which unfortunately never realised given the team's move into Olivetti, where they eventually created Modula-2+ and Modula-3.

ORC is precise, it doesn't do conservative stack marking, ORC's cycle detector uses "trial deletion", not "mark and sweep", ORC removes cycle candidates in O(1) which means it can exploit o
acyclic structures at runtime better than previous algorithms, ORC has a heuristic for "bulk cycle detection"...

ORC seems like a pretty nice solution