Re: Beta 2.107.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Tuesday, 2 January 2024 at 12:49:51 UTC, Iain Buclaw wrote:
Glad to announce the first beta for the 2.107.0 release, ♥ to 
the 35 contributors.




Top-level win{32,64}.mak and legacy src/win{32,64}.mak files 
(for DigitalMars make) have been removed altogether. The 
generic top-level Makefile works on Windows too - with a GNU 
make (and a git installation providing bash and GNU tools).


Wow!

Re: Release D 2.106.1

[Andrej Mitrovic via Digitalmars-d-announce]

On Tuesday, 2 January 2024 at 03:31:47 UTC, Steven Schveighoffer 
wrote:
On Tuesday, 2 January 2024 at 02:48:29 UTC, Andrej Mitrovic 
wrote:
Does anyone know when did named arguments initially land in 
the compiler, as part of which release..? I never saw it as a 
headline feature in any previous release notes.


They are not finished yet, which is why they were not 
announced. Judging by run.dlang.io, it was in 2.103.


-Steve


But are they considered stable? They seem to be documented: 
https://dlang.org/spec/expression.html#argument-parameter-matching

Re: Release D 2.106.1

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 1 January 2024 at 22:02:26 UTC, Iain Buclaw wrote:

Glad to announce D 2.106.1, ♥ to the 4 contributors.

http://dlang.org/download.html

This point release fixes a few issues over 2.106.0, see the 
changelog for more details.


http://dlang.org/changelog/2.106.1.html

-Iain
on behalf of the Dlang Core Team


Does anyone know when did named arguments initially land in the 
compiler, as part of which release..? I never saw it as a 
headline feature in any previous release notes.

Re: First Beta 2.106.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 8 November 2023 at 05:53:32 UTC, Iain Buclaw wrote:
Recursively adding `nothrow:` was implied but I err towards 
brevity.


Alright thanks for clarifying!

Re: First Beta 2.106.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 2 November 2023 at 09:13:55 UTC, Iain Buclaw wrote:

On Thursday, 2 November 2023 at 07:49:32 UTC, Imperatorn wrote:
Why is it named nothrow if what it's really doing is not 
adding the unwinders?
A nothrow switch could imply it's doing something in 
relationship to nothrow, which it doesn't (unless it's 
secretly enforcing nothrow in the codebase).


`-nothrow` is equivalent to putting `nothrow:` at the top of 
every compiled module.


That kind of goes against what it says in the changelog:

Putting nothrow: at the top of the module doesn't influence the 
status for member functions in a class or struct, the nothrow: 
will have to be repeated for each class/struct.


And it also mentions:


The switch does not affect semantic analysis


But surely it has effect on semantics? I assume scope statements 
are disallowed if -nothrow is set and would lead to compilation 
errors?

Re: First Beta 2.106.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 2 November 2023 at 00:57:23 UTC, Iain Buclaw wrote:
Glad to announce the first beta for the 2.106.0 release, ♥ to 
the 33 contributors.


http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.106.0.html

As usual please report any bugs at
https://issues.dlang.org

-Iain
on behalf of the Dlang Core Team


Thanks Iain.

For [Global variables can now be initialized with Associative 
Arrays](https://dlang.org/changelog/2.106.0.html#dmd.static-assoc-array), what exactly is it meant by "globals"?


Variables in module-scope?
Static variables?

Does it also affect AAs in structs? For example:

```d
struct S
{
static int[int] x = [4:4];
}
```

Will this now work?

Re: Walter on Twitter

[Andrej Mitrovic via Digitalmars-d-announce]

On Tuesday, 18 April 2023 at 20:07:43 UTC, Walter Bright wrote:
I'm just afraid it will consist mostly of me staring at the 
screen with a baffled look.


I think that's 99.9% of programmers.

But think of it as rubber duck debugging. 
https://en.wikipedia.org/wiki/Rubber_duck_debugging


I think that having to explain your actions makes one a better 
programmer. It's kind of like PR reviews except it's live.


It's similar to documenting code. If you document your API or 
code and realize the explanation doesn't really make any sense 
then probably the code doesn't make any sense. So it's time to 
rethink that piece of code.

Re: New beginnings - looking for part-time D programming help

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 23 March 2023 at 16:02:46 UTC, Laeeth Isharc wrote:

Hi.

For those that didn't hear, I resigned from Symmetry in 
September and my last day was a couple of weeks back.


Do you believe Symmetry will continue to invest in D after your 
departure?

Re: Release D 2.102.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 2 February 2023 at 12:30:50 UTC, Iain Buclaw wrote:

http://dlang.org/download.html


Seems there's problems with the installer script: 
https://issues.dlang.org/show_bug.cgi?id=23671

Re: Release D 2.102.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 2 February 2023 at 12:30:50 UTC, Iain Buclaw wrote:

http://dlang.org/download.html
http://dlang.org/changelog/2.102.0.html

-Iain
on behalf of the Dlang Core Team


- Stack traces can now be generated when run inside the GC 
collection routine.

- InvalidMemoryOperationError now has a stack trace.

This is awesome.

And thanks for the release Iain.

Re: DConf '22 Day One Videos

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 26 September 2022 at 12:48:54 UTC, Mike Parker wrote:
I've finished editing uploading all of the videos for Day One 
of DConf. You can find them here:


https://www.youtube.com/playlist?list=PLIldXzSkPUXVDzfnBlXcqZF6GB_ejjkEn

I hope to be able to pick up the pace a bit after this week.


Nice work Mike, appreciated!

Re: chain of exceptions, next method

[Andrej Mitrovic via Digitalmars-d-learn]

On Sunday, 14 August 2022 at 02:30:43 UTC, Paul Backus wrote:

On Sunday, 14 August 2022 at 02:07:05 UTC, Ali Çehreli wrote:


This automatic "combining" of exceptions happens for cleanup 
code like scope(exit). (I remember bug(s) for scope(failure).):


To be precise, an exception thrown inside a 'finally' block 
gets chained onto the previous exception, but an exception 
thrown inside a 'catch' block does not. scope(exit) and 
scope(failure) are just syntax sugar for 'finally' and 'catch', 
respectively.


I wish the compiler would rewrite scope(failure) to use chained 
exceptions. Otherwise any exceptions thrown within scope(failure) 
can end up losing information about what was the original 
exception that was thrown.

Re: The D Programming Language Vision Document

[Andrej Mitrovic via Digitalmars-d-announce]

On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:
GC is one of D's strength because it is optional, not making 
core APIs bing-your-own-memory-allocation-strategy through nogc 
or allocators, is making it no longer optional, which is no 
longer a strength imo


You don't want GC when you do microcontroller development, so 
as a result core APIs (most of them) becomes useless, moving 
forward that should make the story better for everyone


Which becomes a strength again!


Sure, I agree with you. I think I was just being pedantic. :)

Re: The D Programming Language Vision Document

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 4 July 2022 at 06:01:09 UTC, Mike Parker wrote:
So what the `@nogc as much as possible` goal means is that it 
should be a consideration for the implementation of Phobos v2 
from the beginning. The design of the API should allow `@nogc` 
client code to make use of it as much as possible.


Fair enough.

Re: The D Programming Language Vision Document

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 4 July 2022 at 05:35:20 UTC, rikki cattermole wrote:


On 04/07/2022 5:30 PM, Andrej Mitrovic wrote:
Aren't these the polar opposites of each other? The GC is one 
of D's strengths, yet we should avoid it as much as possible 
in the standard library.


Not necessarily.

It could and should most likely mean that it won't do any heap 
allocations.


Heap allocations are expensive after all.


@safe @nogc @noheap? :)

Baby, you got a stew going!

Re: The D Programming Language Vision Document

[Andrej Mitrovic via Digitalmars-d-announce]

On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
You can find the final draft of the high-level goals for the D 
programming language at the following link:


https://github.com/dlang/vision-document


Under 'Memory safety':

Allow the continued use of garbage collection as the default 
memory management strategy without impact. The GC is one of D's 
strengths, and we should not "throw the baby out with the bath 
water".


Under 'Phobos and DRuntime':


@nogc as much as possible.


Aren't these the polar opposites of each other? The GC is one of 
D's strengths, yet we should avoid it as much as possible in the 
standard library.


Then it's not part of D's strengths.

Re: New forum view mode "narrow-index" is now available

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 30 June 2022 at 07:09:36 UTC, Ahmet Sait wrote:

Feedback welcome!


Love it! Thank you to everyone involved~

Re: DConf Online 2020 Schedule

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote:
The DConf Online schedule is now live on the website. I've got 
a blog post coming tomorrow which will, among other things, 
include an announcement about the schedule aimed at the world 
outside our community in a form suitable for /r/programming.


https://dconf.org/2020/online/index.html


I'm a bit confused about this sentence:

The D Language Foundation is very pleased to announce that DConf 
Online 2020 (not DConf 2020 Online!) is taking place November 21 
and 22, 2020.


What exactly is the difference between the naming?

Re: Release D 2.094.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 5 October 2020 at 03:27:22 UTC, Andrej Mitrovic wrote:
I'm not sure if it's related to 
https://issues.dlang.org/show_bug.cgi?id=21226. But how many 
people will be turned away not being able to install the 
compiler?


This might have come off a bit rude, apologies for that.

That being said, the solution seemed to be to run the `update` 
command on the script. It wasn't really obvious though.

Re: Release D 2.094.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak 
wrote:

Glad to announce D 2.094.0, ♥ to the 49 contributors.

This release comes with faster compiler binaries (built with 
ldc), direct git dependencies in dub, better type checking of 
vectors, and improved template instantiation diagnostics.


http://dlang.org/download.html
http://dlang.org/changelog/2.094.0.html

-Martin


```
$ curl -fsS https://dlang.org/install.sh | bash -s dmd
Downloading and unpacking 
http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz

 100.0%
gpg: Signature made Tue Sep 22 18:58:37 2020 KST
gpg:using RSA key 
3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8

gpg: Can't check signature: No public key
Invalid signature 
http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz.sig

```

I'm not sure if it's related to 
https://issues.dlang.org/show_bug.cgi?id=21226. But how many 
people will be turned away not being able to install the compiler?

Re: A function to split a range into several ranges of different chunks

[Andrej Mitrovic via Digitalmars-d-learn]

On Monday, 14 September 2020 at 09:08:01 UTC, Seb wrote:

You likely want to get involved / raise your support here:

https://github.com/dlang/phobos/pull/7600


Oh this is great, thank you!

A function to split a range into several ranges of different chunks

[Andrej Mitrovic via Digitalmars-d-learn]

-
import std.range;
import std.stdio;

void main ()
{
auto range = sequence!((a, n) => n);

// works, but the chunks are all the same length
auto rngs = range.chunks(4);
writeln(rngs[0]);
writeln(rngs[1]);
writeln(rngs[2]);

// want this
auto ranges = range.???(3, 4, 5);
writeln(ranges[0] == [1, 2, 3]);
writeln(ranges[1] == [4, 5, 6, 7]);
writeln(ranges[2] == [8, 9, 10, 11, 12]);
}
-

Do you know of a simple way to do this? It's essentially similar 
to chunks, except the chunks themselves would not be of the same 
length.


You can think of a good name for '???' here. Maybe this is 
already possible by combining functionality in std.range - but I 
came up short.

Re: Beta 2.094.0

[Andrej Mitrovic via Digitalmars-d-announce]

On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote:

http://dlang.org/changelog/2.094.0.html

As usual please report any bugs at
https://issues.dlang.org

-Martin


"Equality of arrays of structs is consistent again, as before 
v2.078"


Not a big fan of this. I think it's super dangerous to change 
this behavior again.


Does anyone know when -preview=fieldwise will become the default?

Re: Symmetry Investments and the D Language Foundation are Hiring

[Andrej Mitrovic via Digitalmars-d-announce]

On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote:
Looking for a full-time or part-time gig? Not only is Symmetry 
Investments hiring D programmers, they are also generously 
funding two positions for ecosystem work under the D Language 
Foundation. And they've put up a bounty for a new DUB feature. 
Read all about it here:


https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/


One other thing that hashing enables is caching builds. So if you 
build, then change a file, then build again, and then revert the 
file again it would be great if the next build just restored the 
cached build from the very first build.


The less time spent waiting on builds, the better.

Re: Symmetry Investments and the D Language Foundation are Hiring

[Andrej Mitrovic via Digitalmars-d-announce]

On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote:
Looking for a full-time or part-time gig? Not only is Symmetry 
Investments hiring D programmers, they are also generously 
funding two positions for ecosystem work under the D Language 
Foundation. And they've put up a bounty for a new DUB feature. 
Read all about it here:


https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/


This is a great initiative!

It's also a great opportunity for up-and-coming D contributors. I 
know that if I had this chance back many years ago when I was 
unemployed I would have jumped at the opportunity. So if you're 
in a similar position don't hesitate to apply!

Re: How do I convert an ISO 8601 datetime into a unix timestamp - at compile-time?

[Andrej Mitrovic via Digitalmars-d-learn]

On Friday, 28 August 2020 at 12:35:26 UTC, Steven Schveighoffer 
wrote:

It's trying to look up the local timezone at compile time.

You need to specify a time zone:

static time =
SysTime(DateTime.fromISOString("20220101T00"), 
UTC()).toUnixTime;


-Steve


Aw, thanks Steve!

Re: How do I convert an ISO 8601 datetime into a unix timestamp - at compile-time?

[Andrej Mitrovic via Digitalmars-d-learn]

On Friday, 28 August 2020 at 01:54:02 UTC, Andrej Mitrovic wrote:

-
import std.datetime;

void main ()
{
static time =

SysTime(DateTime.fromISOString("20220101T00")).toUnixTime;

}
-


I think I'm supposed to use MonoTime here, right?

How do I convert an ISO 8601 datetime into a unix timestamp - at compile-time?

[Andrej Mitrovic via Digitalmars-d-learn]

-
import std.datetime;

void main ()
{
static time =

SysTime(DateTime.fromISOString("20220101T00")).toUnixTime;

}
-

-
/Library/D/dmd/src/phobos/std/concurrency.d(2574): Error: static 
variable lock cannot be read at compile time
/Library/D/dmd/src/phobos/std/concurrency.d(2574):called 
from here: atomicLoad(lock)
/Library/D/dmd/src/phobos/std/concurrency.d(2600):called 
from here: initOnceLock()
/Library/D/dmd/src/phobos/std/concurrency.d(2600):called 
from here: initOnce(delegate shared(bool)() pure @nogc @safe => 
init(), initOnceLock())
/Library/D/dmd/src/phobos/std/datetime/timezone.d(1106):
called from here: initOnce(delegate shared(bool)() pure nothrow 
@nogc @safe => (*function () nothrow @nogc @safe => true)())
/Library/D/dmd/src/phobos/std/datetime/timezone.d(546):
called from here: (*& singleton)()
/Library/D/dmd/src/phobos/std/datetime/systime.d(524):
called from here: opCall()
/Library/D/dmd/src/phobos/std/datetime/systime.d(472):
called from here: this.this(dateTime, zero(), tz)
test.d(6):called from here: SysTime(0L, Rebindable(null, 
)).this(fromISOString("20220101T00"), null)

-

I'm sure there must be a better way to do this. But I couldn't 
find it in the documentation.

Re: Why is time_t defined as a 32-bit type on Windows?

[Andrej Mitrovic via Digitalmars-d-learn]

On Wednesday, 5 August 2020 at 16:13:19 UTC, Andrej Mitrovic 
wrote:

```
C:\dev> rdmd -m64 --eval="import core.stdc.time; 
writeln(time_t.sizeof);"

4
```

According to MSDN this should not be the case:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64?view=vs-2019

time is a wrapper for _time64 and **time_t is, by default, 
equivalent to __time64_t**.


But in Druntime it's defined as a 32-bit type: 
https://github.com/dlang/druntime/blob/349d63750d55d078426d4f433cba512625f8a3a3/src/core/sys/windows/stdc/time.d#L42


I filed it as an issue to get more eyes / feedback: 
https://issues.dlang.org/show_bug.cgi?id=21134

Re: Why is time_t defined as a 32-bit type on Windows?

[Andrej Mitrovic via Digitalmars-d-learn]

On Wednesday, 5 August 2020 at 16:13:19 UTC, Andrej Mitrovic 
wrote:

```
C:\dev> rdmd -m64 --eval="import core.stdc.time; 
writeln(time_t.sizeof);"

4
```

According to MSDN this should not be the case:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64?view=vs-2019

time is a wrapper for _time64 and **time_t is, by default, 
equivalent to __time64_t**.


But in Druntime it's defined as a 32-bit type: 
https://github.com/dlang/druntime/blob/349d63750d55d078426d4f433cba512625f8a3a3/src/core/sys/windows/stdc/time.d#L42


It looks like this definition was there from at least 2008 (!!), 
and probably earlier than that but I don't have the SVN sources: 
https://github.com/dlang/druntime/blob/6837c0cd426f7e828aec1a2bdc941ac9b722dd14/import/stdc/time.d#L49



So basically, just around the time the first 64-bit version of 
Windows was released. I'm guessing it was just neglected..

Why is time_t defined as a 32-bit type on Windows?

[Andrej Mitrovic via Digitalmars-d-learn]

```
C:\dev> rdmd -m64 --eval="import core.stdc.time; 
writeln(time_t.sizeof);"

4
```

According to MSDN this should not be the case:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64?view=vs-2019

time is a wrapper for _time64 and **time_t is, by default, 
equivalent to __time64_t**.


But in Druntime it's defined as a 32-bit type: 
https://github.com/dlang/druntime/blob/349d63750d55d078426d4f433cba512625f8a3a3/src/core/sys/windows/stdc/time.d#L42

Re: From the D Blog: A Pattern for Head-mutable Structures

[Andrej Mitrovic via Digitalmars-d-announce]

On Friday, 26 June 2020 at 06:14:48 UTC, Mike Parker wrote:
On Friday, 26 June 2020 at 05:37:13 UTC, Arun Chandrasekaran 
wrote:


This is a very interesting post. But this strategy with HN is 
clearly not working. 5 upvotes after 17 hours and 0 comments. 
Please paste the direct link in future even if the ranking 
goes down after a few hours. Some publicity is better than 
nothing at all.


Upvotes aren't counted when you follow a direct link. So no, I 
won't be posting direct links.


Isn't it possible to just paste to the search results? 
https://hn.algolia.com/?q=A+pattern+for+head+mutable


Then presumably after clicking on comments you would be allowed 
to upvote.

Re: dbox is a complete D2 port of the Box2D game physics library

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 18 June 2020 at 14:38:27 UTC, aberba wrote:
On Wednesday, 17 June 2020 at 01:20:00 UTC, Andrej Mitrovic 
wrote:

On Tuesday, 16 June 2020 at 17:52:37 UTC, aberba wrote:

On Friday, 23 May 2014 at 22:00:51 UTC, Andrej Mitrovic wrote:

https://github.com/d-gamedev-team/dbox

What is Box2D?
==

[...]


This sort of investment still amazes me.


This is a 6 years old post though. I'm sure there are much 
better graphics libraries out there by now, including D ones.


Box2D? Its a physics engine.


Yes sorry about that I remembered it wrong. :)

Anyway I think it would be great to optimize it. If I recall 
right, there was a lot of GC usage in the port.

Re: dbox is a complete D2 port of the Box2D game physics library

[Andrej Mitrovic via Digitalmars-d-announce]

On Tuesday, 16 June 2020 at 17:52:37 UTC, aberba wrote:

On Friday, 23 May 2014 at 22:00:51 UTC, Andrej Mitrovic wrote:

https://github.com/d-gamedev-team/dbox

What is Box2D?
==

[...]


This sort of investment still amazes me.


This is a 6 years old post though. I'm sure there are much better 
graphics libraries out there by now, including D ones.

Re: Interesting work on packing tuple layout

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 15 June 2020 at 15:00:12 UTC, Max Samukha wrote:

On Monday, 15 June 2020 at 14:55:37 UTC, Andrej Mitrovic wrote:

On Monday, 15 June 2020 at 14:18:38 UTC, Timon Gehr wrote:

Apparently, it has been fixed in 2.092. Nice!


Oh wow that's fantastic. Does anyone know which changeset / PR 
fixed it?


The person who fixed that must be commended.


I think it's this one? https://github.com/dlang/dmd/pull/10702

Re: Interesting work on packing tuple layout

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 15 June 2020 at 14:18:38 UTC, Timon Gehr wrote:

Apparently, it has been fixed in 2.092. Nice!


Oh wow that's fantastic. Does anyone know which changeset / PR 
fixed it?

Re: Interesting work on packing tuple layout

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 15 June 2020 at 13:34:18 UTC, Max Samukha wrote:
On Sunday, 14 June 2020 at 23:30:03 UTC, Andrei Alexandrescu 
wrote:
It's really easy if members in the layout are given internal 
names that include information about the original index.


You can construct a list of member aliases in the original 
order and then 'alias this' that:


typeof(t[0]) works fine, but reading or assigning to such a field 
will not work. For example:


void main() {
Tuple!(byte, int, short) t;
writeln(t[0]);
}

test.d(57,23): Error: need `this` for `__value_field_2` of type 
`byte`

Re: Interesting work on packing tuple layout

[Andrej Mitrovic via Digitalmars-d-announce]

On Saturday, 13 June 2020 at 19:11:33 UTC, Andrei Alexandrescu 
wrote:

https://github.com/ZigaSajovic/optimizing-the-memory-layout-of-std-tuple

Would be interesting to adapt it for std.tuple.


I can't see any way of making indexing work *except* by adding a 
Get template inside the tuple.


Currently Tuple supports indexing via `tuple[2]` => gets you the 
third value with its own type.


We cannot use opIndex for this because the tuple can consist of 
multiple types, and index is a runtime parameter when opIndex is 
called.


Now if we had something like `staticOpIndex` in the language 
maybe it could work. I could envision it being something like 
this:


```
struct Tuple (T...)
{
T t;
auto staticOpIndex (size_t index)()  // CT param
{
return t[index];  // or the rearranged index if fields 
are re-ordered

}
}
```

Re: Interesting work on packing tuple layout

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 15 June 2020 at 06:06:40 UTC, Andrej Mitrovic wrote:
Currently Tuple supports indexing via `tuple[2]` => gets you 
the third value with its own type.


It does this via `alias fields this;` basically.

Re: DIP1028 - Rationale for accepting as is

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 27 May 2020 at 13:47:46 UTC, Claude wrote:
On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic 
wrote:
Is the actual problem those `@trusted:` declarations at the 
top of C headers?


There could be a simple solution to that:

Ban `@trusted:` and `@trusted { }` which apply to multiple 
symbols. Only allow `@trusted` to apply to a single symbol. For


IMO, it makes things worse. Because the careless programmer 
will slap @trusted to every declaration (maybe with a script or 
find/replace macro of his editor). So now, we don't know if the 
annotation is greenwashing or careful examination of the 
definition.


The difference is when adding new symbols. If version control is 
used, it would be very obvious in a review whether a new @trusted 
symbol was added or not. A diff typically shows several lines of 
context, and a toplevel `@trusted:` is easy to miss.

Re: DIP1028 - Rationale for accepting as is

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 27 May 2020 at 09:50:50 UTC, Walter Bright wrote:
Un-annotated C declarations should be a red flag to any 
competent QA team. Recognizing a false @trusted is a whole lot 
harder.


Is the actual problem those `@trusted:` declarations at the top 
of C headers?


There could be a simple solution to that:

Ban `@trusted:` and `@trusted { }` which apply to multiple 
symbols. Only allow `@trusted` to apply to a single symbol. For 
example:


---
@trusted:

extern(C) void memcpy (void*, void*, size_t);
extern(C) void write42 (void*);
---

Error.

---
@trusted extern(C) void memcpy (void*, void*, size_t);
@trusted extern(C) void write42 (void*);
---

OK, compiles. The bindings author has clearly added @trusted 
manually to each symbol.


Obviously there are escape hatches like mixins, code generation, 
etc.

Re: DustMite: the General-Purpose Data Reduction Tool (from the D Blog)

[Andrej Mitrovic via Digitalmars-d-announce]

On Monday, 13 April 2020 at 13:06:30 UTC, Mike Parker wrote:
Vladimir has contributed to the blog an article on the 
evolution of DustMite, looking at some of the challenges he had 
to overcome along the way.


The blog:
https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/

Reddit:
https://www.reddit.com/r/programming/comments/g0ihse/dustmite_the_generalpurpose_data_reduction_tool/


I wish I had even half (or quarter?) of the ingenuity of 
Vladimir. Really great write-up. Dustmite helped me reduce many 
compiler bugs in the past and saved me a lot of time.


Thanks so much for writing Dustmite, and implementing the recent 
feature I've requested!

Re: win32 - Windows API declarations for all platforms

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 1 April 2020 at 07:11:44 UTC, Vladimir Panteleev 
wrote:

More details in the README:
https://github.com/CyberShadow/win32#readme


Ohh thanks a lot for this! It will be handy for something I'm 
working on.

Re: DIP 1024---Shared Atomics---Accepted

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 2 January 2020 at 09:41:02 UTC, Walter Bright wrote:

On 1/2/2020 12:01 AM, Manu wrote:
Quick quick, we need a PR to issue deprecation messages for 
those

invalid read/writes! :)


It's already been merged!

https://github.com/dlang/dmd/pull/10209

Some really fast work there :-)


Nice.

There was some initial work on shared a long while back: 
https://github.com/dlang/dmd/commit/276a69327652be8d95607cec142790baae110d0c


It's interesting it took this long to push it to the end. :)

Re: A program that does OCR(Optical Character Recognition) inspired by Neural Networks

[Andrej Mitrovic via Digitalmars-d-announce]

On Friday, 6 December 2019 at 01:07:38 UTC, Murilo wrote:
Hi everyone. I've spent the last weeks working on a program 
which is able to read and understand text from an image 
file(OCR) by using a rudimentary neural network after training 
with a large amount of images(I made them myself, manually). It 
even shows a map of all the parts of the images that have the 
highest synaptic weights(warmer colors). It was made purely in 
D using the arsd library. Below is the link to it if you wish 
to take a look. For now it only understands upper case letters 
from the English alphabet. I'll be adding more over time. 
Cheers.

https://github.com/MuriloMir/Optical-Character-Recognition


Hey!

This looks like great work to learn from! Is there any chance you 
could add a dub file to make it easy to build?

What is the point of a synchronized lock on a single return statement?

[Andrej Mitrovic via Digitalmars-d-learn]

From: 
https://github.com/dlang/phobos/blob/10b9174ddcadac52f6a1ea532deab3310d3a8c03/std/concurrency.d#L1913-L1916:


-
///
final @property bool isClosed() @safe @nogc pure
{
synchronized (m_lock)
{
return m_closed;
}
}
-

I don't understand the purpose of this lock. The lock will be 
released as soon as the function returns, and it returns a copy 
of a boolean anyway. Am I missing something here?

Re: Blog Post: Beating std::visit Without Really Trying

[Andrej Mitrovic via Digitalmars-d-announce]

On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote:

On 10/6/2019 2:59 AM, Paolo Invernizzi wrote:
Well, so there's hope that _very little_ improvements will be 
merged, in a way or another? I mean, there's some sort of 
policy for things like that:


    https://github.com/dlang/phobos/pull/6730

Frankly speaking, the actual situation it's a little 
discouraging...


We want a much higher bar for merging things than historically. 
A smaller, higher quality library is preferable to a kitchen 
sink library.


There is someone actively adding auto-merge labels to pull 
requests even when the pull request author specifically says the 
PR is not ready. So the bar has actually been lowered in recent 
times..


I'm not going to name names because it would be inappropriate, 
but people are beginning to notice.

Re: Five Projects Selected for SAOC 2019

[Andrej Mitrovic via Digitalmars-d-announce]

On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:

...
Solve Dependency Hell:
This is considered as a crucial first step in making Phobos 
available via the DUB registry


I'm guessing this means we might even be able to use multiple 
versions of Phobos one day. However before we do that, we will 
really need to fix the use of globals in Phobos.

Re: We’re hiring Software Engineers! (D language)

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 3 July 2019 at 14:38:48 UTC, Dejan Lekic wrote:

On Tuesday, 2 July 2019 at 08:56:42 UTC, Andrej Mitrovic wrote:

Hi!

BPF Korea is looking to increase the size of its core 
development team in Seoul, South Korea. The job is on-site, 
and the company is willing to sponsor your Visa application 
and will guide you through the entire process.


I've posted this on the LinkedIn's "D Developer Network" - 
https://www.linkedin.com/groups/3923820/


Thanks a lot! And thank you to the person that posted the twitter 
post as well. It's really appreciated!

Re: We’re hiring Software Engineers! (D language)

[Andrej Mitrovic via Digitalmars-d-announce]

On Tuesday, 2 July 2019 at 09:38:58 UTC, Bastiaan Veelo wrote:

On Tuesday, 2 July 2019 at 08:56:42 UTC, Andrej Mitrovic wrote:

Hi!

BPF Korea is looking to increase the size of its core 
development team in Seoul, South Korea.


Congrats! You should be on this page[1] then, would you agree? 
Let me know if you need help with a PR.


Bastiaan.

[1] https://dlang.org/orgs-using-d.html


Great idea! We'll submit a PR probably sometime soon. Thanks!

We’re hiring Software Engineers! (D language)

[Andrej Mitrovic via Digitalmars-d-announce]

Hi!

BPF Korea is looking to increase the size of its core development 
team in Seoul, South Korea. The job is on-site, and the company 
is willing to sponsor your Visa application and will guide you 
through the entire process.


This is an exciting career opportunity to work on a new 
proof-of-stake Blockchain project, where we're striving to design 
and implement solutions to very interesting problems in the 
crypto-space.


You will be working in an agile team among a diverse group of 
individuals, with a background in a variety of software 
engineering fields.


You will also have the opportunity to work with the D programming 
language. We encourage using open-source software as a 
development practice, and the majority of our work is open-source.


If you think this opportunity excites you, please don't hesitate 
to reach out to us! We will be reviewing every application and 
will respond to you in a timely manner.


Submit your application to: care...@bosagora.io

More information and a detailed job description may be found on 
our website: https://bosagora.io/pdf/DDev.pdf

Re: DConf 2019 Livestream

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 8 May 2019 at 10:13:35 UTC, Ethan wrote:

On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote:
The venue uses WebEx for livestreaming. All the information is 
available in this PDF:


https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I


Good news everyone! A Youtube stream will be arriving after the 
lunch break.


Cheers for your patience.


Thanks a lot! Sorry for complaining before, but I've had a lot of 
subpar WebEx experience at a former job and that software suite 
almost never worked, it was quite terrible.


Cheers!

Re: DConf 2019 Livestream

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote:
The venue uses WebEx for livestreaming. All the information is 
available in this PDF:


https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I


"When joining: Please connect using Internet Explorer, not Google 
Chrome or another web

browser."

You guys can't be serious, you're using WebEx?

Re: Anyone have a Vibe.d Diet Template syntax definition for Sublime?

[Andrej Mitrovic via Digitalmars-d-learn]

On Monday, 22 April 2019 at 04:12:11 UTC, Andrej Mitrovic wrote:
Or perhaps for any other editor so I could adapt it and have 
syntax highlighting in Sublime when viewing .dt files.


In the meantime I found this:
https://packagecontrol.io/packages/Pug

It seems to work fairly well.

Anyone have a Vibe.d Diet Template syntax definition for Sublime?

[Andrej Mitrovic via Digitalmars-d-learn]

Or perhaps for any other editor so I could adapt it and have 
syntax highlighting in Sublime when viewing .dt files.

Re: D compilation is too slow and I am forking the compiler

[Andrej Mitrovic via Digitalmars-d-announce]

On Thursday, 22 November 2018 at 11:16:26 UTC, Paolo Invernizzi 
wrote:
BTW, it's nice to see again the Secret Squirrel on the forum, 
in these days: welcome back Andrej!


/Paolo


Oh hey there too! I'm sorry if I can't recall you, though. 
¯\_(ツ)_/¯


I mostly lurk around here these days. But I still use D heavily, 
at work.

Re: D compilation is too slow and I am forking the compiler

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright 
wrote:
Unfortunately, you're right. The title will leave the 
impression "D is slow at compiling". You have to carefully read 
the article to see otherwise, and few will do that.


Well comparative to itself sometimes it is. When you initially 
write D code you get used to the blazing fast speeds, but when 
eventually the compilation speed slows down as a project grows 
then this has a real effect on productivity.


Maybe a better title would have been "D compilation sometimes 
slows down too much", but it wouldn't get as many hits. On the 
upside, people who read the article - or even just read the 
comments section, will quickly realize that D's compilation speed 
is still miles faster than the competition. They might actually 
try the language. :)

Re: DMD backend now in D

[Andrej Mitrovic via Digitalmars-d-announce]

On Sunday, 11 November 2018 at 23:40:16 UTC, Walter Bright wrote:

As:

https://github.com/dlang/dmd/pull/8946

removes the header files for the old C++ code!


Congrats to everyone!

Re: D's Newfangled Name Mangling

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 20 December 2017 at 13:57:20 UTC, Mike Parker wrote:

The blog
https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/


it won’t catch every error; for example, structs, classes and 
other user defined types are mangled > by name only, so that a 
change to their definition will still pass unnoticed by the 
linker.


Wouldn't it be possible to append the hash of the struct's type 
definition to make the changes to the struct's definition 
noticeable during linking?


e.g.:

-
module test;

struct S
{
int x;
float y;
}

void foo ( S s ) { }
-

You might create a hash this way:

hash = Fnv1a(mangle(Tint32), mangle(Tfloat32));

And then foo's name mangle changes from:
_D4test3fooFS4test1SZv

to:
_D4test3fooFS4test1SZv

It may not be 100% fool-proof yet though, because we'd also have 
to hash a bunch of other things like align() attributes.


Or is this is overkill?

Re: mysqln - tagged bugfix release v1.1.1

[Andrej Mitrovic via Digitalmars-d-announce]

On Wednesday, 20 September 2017 at 05:24:14 UTC, Nick Sabalausky 
(Abscissa) wrote:

https://github.com/mysql-d/mysql-native

Native D client driver for MySQL/MariaDB, works with or without 
Vibe.d


Hey Nick,

Can this also work with Percona MySQL? Or perhaps maybe in the 
future.. :)


Cheers!

Re: Who maintains the D website?

[Andrej Mitrovic via Digitalmars-d]

On Thursday, 3 August 2017 at 00:48:41 UTC, Andrej Mitrovic wrote:
On Thursday, 3 August 2017 at 00:26:31 UTC, Moritz Maxeiner 
wrote:
On Thursday, 3 August 2017 at 00:18:38 UTC, Andrej Mitrovic 
wrote:
Is there a single person who's the main maintainer of the D 
website..?



If not, I have some ideas on how to improve it. Not just 
ideas, I'd like to give a host at improving it myself, really.


AFAIK the website is maintained via git here [1].
If you want to improve something, you can create a PR / open 
an issue there.


[1] https://github.com/dlang/dlang.org


Oh, I get that much. But I was wondering if there was a 
webmaster who approve disapproved changes to the site.


Sorry, bad typos here. I meant a webmaster who approved /or/ 
disapproved changes to the website.

Re: Who maintains the D website?

[Andrej Mitrovic via Digitalmars-d]

On Thursday, 3 August 2017 at 00:26:31 UTC, Moritz Maxeiner wrote:
On Thursday, 3 August 2017 at 00:18:38 UTC, Andrej Mitrovic 
wrote:
Is there a single person who's the main maintainer of the D 
website..?



If not, I have some ideas on how to improve it. Not just 
ideas, I'd like to give a host at improving it myself, really.


AFAIK the website is maintained via git here [1].
If you want to improve something, you can create a PR / open an 
issue there.


[1] https://github.com/dlang/dlang.org


Oh, I get that much. But I was wondering if there was a webmaster 
who approve disapproved changes to the site.



Anyway, I'll come up with something new soon and share it with 
W, I really think the website could use a better presentation.

Re: Who maintains the D website?

[Andrej Mitrovic via Digitalmars-d]

On Thursday, 3 August 2017 at 00:18:38 UTC, Andrej Mitrovic wrote:
Is there a single person who's the main maintainer of the D 
website..?



If not, I have some ideas on how to improve it. Not just ideas, 
I'd like to give a host at improving it myself, really.


Sorry that was a weird typo. I meant, I'd like to give a try at 
improving it myself.

Who maintains the D website?

[Andrej Mitrovic via Digitalmars-d]

Is there a single person who's the main maintainer of the D 
website..?



If not, I have some ideas on how to improve it. Not just ideas, 
I'd like to give a host at improving it myself, really.

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors.



Mike, given the general feedback I've received here, I think the 
next best take of action is to split the implicit inheritance 
proposal into a separate, smaller DIP, and update DIP 1004 with a 
second draft.


Thoughts?

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Wednesday, 3 May 2017 at 12:58:17 UTC, Daniel N wrote:
The trick is that your child class need to have defined at 
least 1 constructor before the alias.


This should work:
this() {}
alias __ctor = super.__ctor;

This will give the error message you saw:
alias __ctor = super.__ctor;
this() {}


I see. It does look like an accidental feature (as in, that it 
could break in the future).

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Wednesday, 3 May 2017 at 09:13:54 UTC, Daniel N wrote:
However I oppose the other part of the DIP since it's already 
possible today.


class FileException : Exception
{
this(ErrorCode error_code, string file = __FILE__, uint 
line = __LINE__ )

{
super("FileNotFound", file, line);
}

alias __ctor = super.__ctor;
}


I was excited for a second, but that doesn't actually compile.

Error: alias test.FileException.__ctor is not a constructor; 
identifiers starting with __ are reserved for the implementation

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
100% in favor of the constructor behavior change in case no 
constructor is in the derived class.


I think we could even split this up into two separate proposals, 
because this part of the DIP is fairly non-controversial and 
could be approved much faster (and implementation-wise it should 
be fairly simple to support).

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Monday, 1 May 2017 at 19:02:11 UTC, H. S. Teoh wrote:
1) Suppose my base class has 3 ctors, and I only want my 
derived class to inherit 1 of them. Does this DIP allow for 
that?


Initially when designing the DIP I haven't thought about this 
use-case, but I've had more thought put into it recently. 
Unfortunately it came a bit late, but I thought about an 
alternate DIP design to this one, where instead of inheriting 
*all* base class ctors, the user would selectively inherit 
*specific* ctors. The alternate proposal is just a PR for now: 
https://github.com/dlang/DIPs/pull/60 (direct link 
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md)


2) If my derived class has no ctors (and the base class has a 
default ctor but also several other ctors), what if I want to 
suppress inheriting base class ctors (except the default)?  Do 
I need to individually list all base class ctors and attach 
@disable to them? How would this interact with future-proofing 
my derived class in case the base class changes in the future 
(e.g., more ctors got added)?


Very good question, especially about future-proofing. This goes 
back to my response to #1, and makes me think that in fact the 
alternate design in https://github.com/dlang/DIPs/pull/60 is 
probably a better idea.


3) Is it legal to write `@disable this(int,int)` when the base 
class doesn't have a matching ctor?  This might happen, e.g., 
if the base class ctor was removed after the fact.  Or would 
all derived classes that disabled the original ctor have to be 
updated?


It would have to be illegal.

4) If my derived class has no (explicit) ctors, is there any 
semantic

difference between writing:

class Derived : Base {}

vs.:

class Derived : Base { alias super.this this; }
?


There shouldn't be any semantic difference.

Would it be better to require the latter explicit form so that 
this DIP is opt-in (and also prevents breaking existing code 
that uses compile-time introspection)?


I'm not really sure of real-world examples where this would be 
the case, where a class designer has explicitly derived from a 
class but failed to write any constructors *and* intends for that 
class not to be constructible. In such a case, surely the 
designer of the class would label the class as `abstract`.


Or would the added boilerplate (have to write that alias line 
for all derived classes) make this DIP less attractive? (Note 
that this essentially nullifies implicit ctor inheritance, 
which is one of main points of this DIP. But the point is that 
alternatives like this should be considered and argued against 
to make this DIP stronger.)


I feel like implicit constructor inheritance where there are no 
new additional constructors being introduced in the derived class 
would be a safe default to have. I can't imagine a case where 
this would cause bugs in user code. But I'm open to seeing such 
examples, of course.


5) How would this DIP interact with access controls? E.g., if 
the base class has a private ctor, will that be inherited 
implicitly? Or if the base class has a protected ctor, will the 
inherit ctor remain as protected?


Not unless the two classes were part of the same module (and thus 
had symbol visibility). However the implicitly inherited 
constructor would also be private in the derived class as well, 
so that should answer the second part of that question.


Will there be a way to inherit a base class protected ctor and 
make it public instead? (I.e., a form of forwarding, from a 
public derived class ctor to a protected base class ctor.)


Interesting idea. That would be another point for the alternate 
proposal in 
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md, which would allow code such as:


class A { protected this ( int x ) { } }
class B { public alias super.this(int) this; }

If the base class introduces new private ctors, will that cause 
any problems with derived classes implicitly inheriting all 
ctors (assuming they do inherit private ctors)?


At what point does it cross the line of requiring explicit 
declaration of a forwarding ctor in the derived class?


It's hard to tell whether it would cause problems, although it is 
indeed possible to accidentally inherit a ctor even if it's 
unwanted.


I see the general sentiment, and I think the big question to be 
asked here is: do we want a way to inherit "everything at once", 
or have a simple syntax to selectively inherit some constructors 
as in 
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md.

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Monday, 1 May 2017 at 18:34:43 UTC, H. S. Teoh wrote:
so the fact that they now have different syntaxes was seen as 
an advantage.


Yeah, I remember that decision. I don't think I've ever agreed 
with it, though. :o)


We'll see.. I don't personally find it very important, I'm fine 
with either styles of syntax.

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors. [...]
All review-related feedback on and discussion of the DIP 
should occur in this thread. [...]

Destroy!


An obvious omission in the syntax variations [1]

- alias this() = super.this();

or

- alias this = super.this;


I thought people would catch on that this is implied. :) The 
old-style or new-style alias syntax should both be allowed, in my 
opinion. The main issue is what to do about the parentheses, 
whether to include them or not.

Re: DConf 2017 Berlin - Streaming ?

[Andrej Mitrovic via Digitalmars-d]

On Saturday, 29 April 2017 at 17:58:15 UTC, Joakim wrote:
Any update on the stream this year, for those of us planning to 
watch the talks remotely?


The last bit of news I've received is they will be streamed on 
youtube this time.

Re: DIP 1005 - Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Sunday, 23 April 2017 at 16:39:35 UTC, deadalnix wrote:
It's just one per module. Templates are only instantiated once 
per new set of arguments. There may be some gain here, but I 
doubt this is worth adding a new language feature.


Ah, good point.

Though there's still merit to this DIP such as this:

With this syntax, the import is executed only if the declared 
name (process) is actually looked up.


I don't believe the workaround with the `from` template fixes 
this.

Re: DIP 1005 - Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu 
wrote:
Mostly out of a sense of conformity. We asked Michael to give 
no special treatment of DIPs originating from us, and this one 
was open, so he put it up for review. It is likely it will end 
up rejected in favor of 
https://github.com/dlang/druntime/pull/1756.


Wouldn't there be a compile-time performance impact from 
instantiating so many templates, virtually for every parameter 
who's type is defined in another module?

Re: DIP 1005 - Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Saturday, 22 April 2017 at 16:14:29 UTC, Timon Gehr wrote:
Please reconsider. This is new syntax. It looks like old syntax 
but behaves differently.


I suppose the biggest issue is:

-
module mod;
import std.stdio;

struct A
{
~this ( ) { writeln("dtor"); }
}
-

-
module test;

class C
{
with (import mod) A a;  // declaration, lives as long as C 
lives


void test ( )
{
with (import mod)  // statement
{
A a; // destroyed on exit of scope
}

// a was destroyed, and is not even visible here
}
}
-

I can see how this can be a pain point. If it's a big worry then 
I'd be ok with using one of the syntactic alternatives, like 
'import (std.stdio);'.

Re: DIP 1005 - Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md


Very solid DIP! And I like the use of `with` and it's proposed 
extension to be allowed in declarations, rather than introducing 
new syntax.

Re: DIP 1005 - Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md


with (Type) and with (TemplateInstance) are always declarations 
and do not introduce a new scope.


Does that mean we can now do things like this?:

-
module m;
struct A { struct B { } }
with (A) B b;
-

That's a pretty cool addition.

Re: Beta 2.074.0-b1

[Andrej Mitrovic via Digitalmars-d-announce]

On Friday, 24 March 2017 at 17:35:58 UTC, Martin Nowak wrote:

First beta for the 2.074.0 release.

This release comes with plenty of phobos additions and a new 
std.experimental module.


http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.074.0.html


Please report any bugs at https://issues.dlang.org

-Martin


Very cool about the new format!() feature. What about extending 
this to writef(ln)?

Re: Google is apparently now better at searching programming-related questions

[Andrej Mitrovic via Digitalmars-d]

On Friday, 3 March 2017 at 07:51:06 UTC, Ola Fosheim Grøstad 
wrote:
I get those same results when using my regular browser, but 
when using another browser I get "ad lib" etc, nothing about 
programming.


You may be right. :)

I mistakenly thought the lack of cookies would be enough to get 
clean results. So much for that!

Google is apparently now better at searching programming-related questions

[Andrej Mitrovic via Digitalmars-d]

https://9to5google.com/2017/03/02/google-search-technical-queries-programming-languages/

I just used a private session and opened google, searched for "d 
libs" and the first three results were the DWiki and a Github 
project, https://wiki.dlang.org/Libraries_and_Frameworks, 
https://wiki.dlang.org/GUI_Libraries, and 
https://github.com/zhaopuming/awesome-d.


Pretty decent!

I don't know what it looked like before, but I do know a lot of 
people complain about D being unsearchable. I also heard these 
complaints about Go as well, so D isn't alone in this.


If any of you have had issues with searching for D, could you 
give us an update on whether these rolled-out changes by Google 
have had any effect?

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrej Mitrovic via Digitalmars-d]

On Thursday, 15 December 2016 at 17:07:35 UTC, Dominikus Dittes 
Scherkl wrote:
On Thursday, 15 December 2016 at 16:16:51 UTC, Walter Bright 
wrote:

On 12/14/2016 5:26 AM, Dominikus Dittes Scherkl wrote:

Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the 
declaration, so that

the symbols imported can be used in the declaration?

e.g.

fun(Range x) if(isInputRange!x)
{
   import std.range;
   auto a = x.front();
}


That would make it problematic to have function declarations.
So, I no longer propose to change nothing except the internal 
compiler behaviour.
Now I propose to additionally change the .di-file generation to 
also add all local imports to the start of the declaration 
file, so that having this file gives ALL dependencies of the 
declared stuff.


This makes me think about the current .di generation. As far as I 
remember it only strips function bodies and leaves everything 
else intact. It could already try to remove unused imports. And 
in the future it could replace regular imports with 
auto-generated DCD-style imports.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrej Mitrovic via Digitalmars-d]

On Thursday, 15 December 2016 at 00:44:02 UTC, Andrej Mitrovic 
wrote:
On Wednesday, 14 December 2016 at 23:38:19 UTC, Timon Gehr 
wrote:

On 15.12.2016 00:17, Andrej Mitrovic wrote:


ubyte[] readSomeBytes ( )
{
return read(1024);
}

It's a non-trivial exercise for the reader to understand 
where the

`read` symbol is coming from.


pragma(msg,fullyQualifiedName!read);


Right, which requires building!


Also, this wouldn't work with overloads would it? :)

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrej Mitrovic via Digitalmars-d]

On Wednesday, 14 December 2016 at 23:38:19 UTC, Timon Gehr wrote:

On 15.12.2016 00:17, Andrej Mitrovic wrote:


ubyte[] readSomeBytes ( )
{
return read(1024);
}

It's a non-trivial exercise for the reader to understand where 
the

`read` symbol is coming from.


pragma(msg,fullyQualifiedName!read);


Right, which requires building!

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrej Mitrovic via Digitalmars-d]

On Wednesday, 14 December 2016 at 22:55:26 UTC, Andrei 
Alexandrescu wrote:
Made a pass through the document integrating a lot of feedback 
and fleshing the proposal better:


https://github.com/andralex/DIPs/blob/155ff59984b26749af7830aeb172d3af2dae8cd7/DIPs/DIP1005.md

https://github.com/dlang/DIPs/pull/51/files


Andrei


I'd also mention that the advantage of this feature is for the 
human reader (and not just ddoc generators) as you can instantly 
tell where all the symbols are located which a function uses. It 
could save a lot of time for the reader when analyzing a function.


For example, if we have a function like the following:

ubyte[] readSomeBytes ( )
{
return read(1024);
}

It's a non-trivial exercise for the reader to understand where 
the `read` symbol is coming from. It usually involves looking up 
the import list at the top of the module which is typically very 
long and contains unrelated imports as the DIP mentions.


Sometimes you can use a symbol lookup shortcut in your editor, 
but with a name like `read` you'll likely get a dozen modules 
listed in the pop-up and you still couldn't immediately tell 
which one of the symbols this `read` call refers to. Someone will 
mention IDEs, but remember when you're looking at the code in 
another environment (say reviewing code on Github) you may not 
have quick point & click functionality to find the symbol 
declaration. That's another win for this DIP.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrej Mitrovic via Digitalmars-d]

On Wednesday, 14 December 2016 at 17:09:44 UTC, ketmar wrote:

bool equal(R1, R2) : std.range, std.traits
if (isInputRange!R1 && isInputRange!R2 && isArray!R2)
{ ... }


breaks possible selective import. if both modules exports some 
symbol, we will need to selectively import and/or rename it.


Not necessarily. The first colon is the only special case, 
afterwards you can use all forms of imports:


bool equal(R1, R2) : std.range : isInputRange, Trait = 
std.traits

if (isInputRange!R1 && isInputRange!R2 && Trait.isArray!R2)
{ ... }

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrej Mitrovic via Digitalmars-d]

On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu 
wrote:

Destroy.

https://github.com/dlang/DIPs/pull/51/files


Andrei


How about:

bool equal(R1, R2) : std.range
if (isInputRange!R1 && isInputRange!R2)
{ ... }

It's nice and concise, and you could in theory also allow 
multiple imports with a comma


bool equal(R1, R2) : std.range, std.traits
if (isInputRange!R1 && isInputRange!R2 && isArray!R2)
{ ... }

Re: If Statement with Declaration

[Andrej Mitrovic via Digitalmars-d]

On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:


So I was thinking of a way of extending if statements that have 
declarations. The following being as example of the current use 
of if statements with declarations:


if(int* weDontPollute = someFunc())
{
 // use weDontPollute
}

That's great and all, but it only works by checking if the 
variable evaluates to true or false. Which is fine for a 
pointer but otherwise useless for anything else, like integers 
where zero is usually valid input (index for array).


This is already possible in library code. See here: 
https://github.com/AndrejMitrovic/minilib/blob/510460ff1381f765a66aa3b8f8f6d7e95b4597b9/src/minilib/core/types.d#L88-L137


One could come up with a helper function that encodes the 
condition which is moved into the opCast method. This should be 
trivial to implement.

Re: Examples Wanted: Usages of "body" as a Symbol Name

[Andrej Mitrovic via Digitalmars-d]

On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
I'm currently writing up a DIP to propose removing `body` as a 
keyword to allow it to be used for variable names, functions, 
etc. I'm looking for examples and contexts where `body` would 
normally be used as a variable, function name, alias, etc. This 
is what I have come up with off the top of my head:


- In web programming where "body" is a required tag in any 
valid HTML document. Ex:

- It is a name commonly used for XML tags and/or attributes
- Physics simulations as well in astronomical contexts 
("planetary bodyies", etc.)

- Video games, such as referring to the player character's body


Physics libraries absolutely.

https://github.com/d-gamedev-team/dchip/blob/55f43e5f0cf67c8bc190711b69eb16230fa6188e/src/dchip/cpBody.d#L184
https://github.com/d-gamedev-team/dbox/blob/6f81fe065abec1e7def44fc777c5d8e9da936104/examples/demo/tests/bodytypes.d#L103

And in various C / C++ libraries. It's rather annoying that body 
is taken, it's a fairly rarely used keyword in D but often used 
in other languages.

Re: Cannot access template name from within template

[Andrej Mitrovic via Digitalmars-d]

On Tuesday, 4 October 2016 at 22:43:21 UTC, Andrei Alexandrescu 
wrote:

On 10/04/2016 06:03 PM, Andrej Mitrovic wrote:

template TemplateOf(T)


Have you forgotten you submitted this to phobos? :o) -- Andrei


I forgot about that template. But that wasn't me: 
https://github.com/dlang/phobos/pull/1884 :)


I added isInstanceOf 
https://github.com/dlang/phobos/commit/e02593090a909948183921f6f00039ce3f37acff

Re: Cannot access template name from within template

[Andrej Mitrovic via Digitalmars-d]

On Monday, 3 October 2016 at 22:28:46 UTC, Andrei Alexandrescu 
wrote:

Any known workaround?


If you're ok with the hacky approach:

-
import std.algorithm;
import std.conv;

/// these are in std.traits but private for whatever reason
alias Identity(alias A) = A;
alias parentOf(alias sym) = Identity!(__traits(parent, sym));
alias parentOf(alias sym : T!Args, alias T, Args...) = 
Identity!(__traits(parent, T));


/// alias itself to the symbol of template instance T
template TemplateOf(T)
{
enum name = T.stringof;

// strip everything after '!' (instantiation args)
enum unqual_name = name.until!(a => a == '!').to!string;

mixin("alias TemplateOf = parentOf!T." ~ unqual_name ~ ";");
}

template SomethingCool(alias X)
{
pragma(msg, X.stringof);  // sanity check
alias Y = X!int;
}

struct MyStruct(T)
{
alias A = SomethingCool!(TemplateOf!MyStruct);
}

struct Outer
{
struct Nested(T)
{
   alias A = SomethingCool!(TemplateOf!Nested);
}
}

void main ( )
{
alias MyStruct!int X;
alias Outer.Nested!int Y;
}
-

Re: Ah, simple solution to unittests inside templates

[Andrej Mitrovic via Digitalmars-d]

On Sunday, 18 September 2016 at 12:02:47 UTC, Andrei Alexandrescu 
wrote:
That suggests the unittest shall be evaluated during 
compilation. -- Andrei


Nah, static is already quite overloaded and needs context to 
understand what it does. For example module constructors.


Anyway compiler issues aside it's probably best to use working 
solutions like yours for now, and later we can devise something 
better via a DIP (one was posted here).


As the saying goes, don't let great be enemy of the good.

Re: Ah, simple solution to unittests inside templates

[Andrej Mitrovic via Digitalmars-d]

On Saturday, 17 September 2016 at 17:22:52 UTC, Andrei 
Alexandrescu wrote:
The unittest documentation is nicely generated. The unittest 
code itself is only generated for one instantiation.


I had a similar thought, but I didn't really like verbosity of 
the static if.


I think at some point someone suggested we could implement 
explicit support for such unittests via `static unittest`:


/** Awesome struct */
struct Awesome(T)
{
/** Awesome function. */
void awesome() {}

///
static unittest
{
Awesome!int awesome;
awesome.awesome;
}
}

A static unittest would not have implicit access to anything 
internal in the aggregation (this is different to your solution 
where the unittest has access to all fields of the Awesome!int 
instance).


Note the difference inside the unittest: it uses `Awesome!int 
awesome` instead of the previous `Awesome awesome`. In your case 
it implicitly refers to the Awesome!int instantiation, however 
you're actually presenting uncompilable code to the user! The 
user might copy-paste it into a main function but it would fail 
to build.


So the feature might have some merit as it would avoid generating 
docs with code which may not even work.

Re: From the D Blog -- GSoC Report: Step

[Andrej Mitrovic via Digitalmars-d-announce]

On 9/9/16, Mike Parker via Digitalmars-d-announce
 wrote:
> Wojciech Szęszoł has contributed a post describing his experience
> working on DStep for this year's GSoC. The post is at [1] and is
> on reddit at [2].

With regards to Sets missing from the language:

-
struct Set(T)
{
void[0][T] set;  // void[0] should not allocate (according to
ancient manuscripts)
alias set this;

void put ( ) ( auto ref T input )
{
this.set[input] = [];
}
}

void main ( )
{
Set!int set;

set.put(1);
set.put(5);

assert(1 in set);
assert(5 in set);
assert(4 !in set);
}
-

I'm not sure about any special syntax which is expected for languages
which have built-in sets. It would probably be overkill to add syntax
support, but I'm not sure how often people use set literals or not.

Re: dlang-vscode

[Andrej Mitrovic via Digitalmars-d]

On 9/6/16, John Colvin via Digitalmars-d  wrote:
> I've used it a bit. See also:

VS code is pretty solid!

I'm too used to Sublime to start using it now, but the fact it's
open-source is a huge plus. Some of its addons are pretty great, for
example you can run an opengl shader and have its output display in
the editor.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Andrej Mitrovic via Digitalmars-d]

On 9/3/16, Martin Nowak via Digitalmars-d  wrote:
> On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote:
>> Ugh, it really should just give everything and have getMember
>> bypass it. That won't even break any code!
>
> It will, e.g. having getMember bypass protection means vibe.d
> would now serialize private members

Then just add a check in vibe.d itself to avoid serializing private
members. You can still call getProtection on the symbol and skip
serializing it.

Alternatively you can use UDAs so you can mark which fields should or
shouldn't be serializible. For example
https://github.com/msgpack/msgpack-d/blob/6046808c2e678e27cb2e2d9314241c361a6fd0ae/src/msgpack/attribute.d#L21

The bottom line is with restricting access to private symbols you have
no choice on the matter, while allowing access lets you specialize
whether to ignore the symbols or not.

Re: Fallback 'catch-all' template functions

[Andrej Mitrovic via Digitalmars-d]

On 9/1/16, Manu via Digitalmars-d  wrote:
> So, consider a set of overloads:
>
>   void f(T)(T t) if(isSomething!T) {}
>   void f(T)(T t) if(isSomethingElse!T) {}
>   void f(T)(T t) {}
>

Best thing I can think of is to use a forwarding template:

-
import std.stdio;

// forwarding (or dispatching) template
void f(T)(T t)
{
static if(is(typeof( fImpl(t) )))  // found match
{
fImpl(t);
}
else  // no matches, use fallback
{
fallback(t);
}
}

void fImpl(T)(T t) if (is(T == int)) { writefln("Int: %s", t); }
void fImpl(T)(T t) if (is(T == float)) { writefln("Float: %s", t); }
void fallback(T)(T t) { writefln("Generic: %s", t); }

void main ( )
{
f(int(1));
f(float(1.0));
f("string");
}
-

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Andrej Mitrovic via Digitalmars-d]

On 8/31/16, Ali Çehreli via Digitalmars-d  wrote:
> v2.071.2-b3 is bringing a change for this bug:
>
>https://issues.dlang.org/show_bug.cgi?id=15907

PSA: If all one cares about are UDAs for fields and not functions then
.tupleof is still a viable workaround. Working example:

-
import getSymbols;

enum UDA;

struct S
{
@UDA float visible;

float dont_care;

private @UDA int invisible;
}

void main()
{
static assert(getSymbolsByUDA!(S, UDA).length == 2);
static assert(getSymbolsByUDA!(S, UDA).stringof == "tuple(visible,
invisible)");
}
-

-
module getSymbols;

import std.meta : AliasSeq;
import std.traits : staticIndexOf;

template getSymbolsByUDA ( T, alias uda )
{
alias getSymbolsByUDA = getSymbolsByUDAImpl!(T, uda);
}

template getSymbolsByUDAImpl ( T, alias uda, size_t idx = 0 )
{
static if (idx + 1 < T.tupleof.length)
{
static if (hasUDA!(T.tupleof[idx], uda))
alias Field = AliasSeq!(T.tupleof[idx]);
else
alias Field = AliasSeq!();

alias getSymbolsByUDAImpl = AliasSeq!(Field,
getSymbolsByUDAImpl!(T, uda, idx + 1));
}
else
{
static if (hasUDA!(T.tupleof[idx], uda))
alias getSymbolsByUDAImpl = AliasSeq!(T.tupleof[idx]);
else
alias getSymbolsByUDAImpl = AliasSeq!();
}
}

template hasUDA ( alias field, alias uda )
{
enum hasUDA = staticIndexOf!(uda, __traits(getAttributes, field)) != -1;
}
-

This is the reason msgpack-d still works and wasn't broken by the change.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Andrej Mitrovic via Digitalmars-d]

On 8/31/16, Ali Çehreli via Digitalmars-d  wrote:
> mixin getSymbolsByUDA!(S, UDA) symbols;

This is such a bizarre workaround to be listed in the changelog since
mixing in non-mixin templates is not an official feature (am I
wrong?). getSymbolsByUDA is a template, not a mixin template.

Re: On the future of DIP1000

[Andrej Mitrovic via Digitalmars-d-announce]

On 8/21/16, Dicebot via Digitalmars-d-announce
 wrote:
> This week I had a tele-meeting with Andrei and Walter regarding
> the fate
> of DIP1000
> (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)

Trivia question: why is it named DIP 1000? We've had less than 100
DIPs before https://github.com/dlang/DIPs was opened, the jump seems
very arbitrary to me (and it makes it appear as if we had a thousand
DIPs already to the outsiders)

Re: Asio Bindings?

[Andrej Mitrovic via Digitalmars-d-learn]

On 6/9/16, Joerg Joergonson via Digitalmars-d-learn
 wrote:
> Why would bindings have any issues with licensing?

Just to show that I'm not full of shit, here's the e-mail chain:

On 6/3/11, Andrej Mitrovic  wrote:
> Hello,
>
> I'm currently porting the Steinberg VST and ASIO SDKs for use with the
> D programming language. I would like to know if there are any special
> licensing requirements before I can publish the source code to a
> public repository.
>
> Specifically, do I need to print out the licensing agreement PDF
> document, sign it, and send it via snail-mail to Steinberg? I'm
> currently unemployed, so there shouldn't be any issues from my part
> with regards to signing any licensing agreements, if that's required.
>
> The bindings themselves won't distribute any C/C++ header or
> implementation files from the SDK, as the D language can't use C
> header files directly.
>
>
> Kind regards,
> Andrej Mitrovic
>



On 6/7/11, Yvan Grabit  wrote:
> Hi Andrej
>
> i will speak with our internal Product planning people about your
> concern...
> I will keep you inform about our decision as soon as we have a decision...
>
> Cheers
>
> Yvan
> 
> Yvan Grabit  mailto:y.gra...@steinberg.de
> Technical Manager - Technology Group Phone: +49-40-21035125
> Steinberg Media Technologies GmbHFax  : +49-40-21035300
> Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany
>  http://www.steinberg.net
> 



On 6/23/11, Andrej Mitrovic  wrote:
> Hello Yvan,
>
> I apologize if this e-mail is unnecessary and a decision is yet to be
> made. If you are too busy should I try to contact one of Steinberg's
> official representatives?
>
> I am willing to provide the source code for examination to Steinberg
> if this could help  verify that I'm not breaking any licensing
> requirements.
>
> Have a nice day,
> Andrej Mitrovic
>


On 6/23/11, Yvan Grabit  wrote:
> Hi
>
> we have examine your request, and decide due to our current VST/ASIO
> license that you are not allowed to deploy/distribute a copy of the
> VST/ASIO SDK (partially or full).
> We will investigate a way to change our licensing for research or
> educational use.
>
> In your concrete case, could it be not possible to ask the people you give
> your source using the VST SDK (or ASIO)  to download the VST-SDK (or ASIO)
> (and agree the agreement) and provide a compiler macro (or something
> different) which will convert the VST /ASIO interface to something D
> compatible ?
>
> By the way how can we guaranty that the VST plugin or ASIO component
> developed in D could be load by a host developed in C ?
>
> Cheers
>
> Yvan
>
> 
> Yvan Grabit  mailto:y.gra...@steinberg.de
> Technical Manager - Technology Group Phone: +49-40-21035125
> Steinberg Media Technologies GmbHFax  : +49-40-21035300
> Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany
>  http://www.steinberg.net
> 



On 6/23/11, Andrej Mitrovic  wrote:
> On 6/23/11, Yvan Grabit  wrote:
>> In your concrete case, could it be not possible to ask the people you
>> give
>> your source using the VST SDK (or ASIO)  to download the VST-SDK (or
>> ASIO)
>> (and agree the agreement) and provide a compiler macro (or something
>> different) which will convert the VST /ASIO interface to something D
>> compatible ?
>
> Yes, I believe I can do that. For ASIO, I have the following:
>
> - A "Loader", which is a source file made from scratch which searches
> for ASIO entries in the Windows Registry and provides a class which
> can load and initialize any found ASIO drivers. Through this class
> user code calls functions like "canSampleRate", "outputReady", etc.
>
> The Loader only requires the type definitions found in the
> asiosdk\common\asio.h header file. This header file can be
> automatically converted to D via an existing tool, and the Loader
> would then import the newly converted header file and use the type
> definitions.
>
> The Loader requires the OpenAsio DLL that can be found here:
> http://www.martinfay.com/openasio.htm
>
> The reason OpenAsio is required is because the ASIO COM class has the
> "thiscall" calling convention which is not directly supported by the D
> language. It might be possible to use inline assembler to simulate the
> "thiscall" calling convention, but this would require some work on my
> part to get it working.
>
> No other ASIO SDK file is required.
>
> From my current understanding, you would require me that