Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 04:30:03 UTC, Nicholas Wilson wrote:

On Sunday, 1 April 2018 at 04:11:37 UTC, Uknown wrote:
On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu 
wrote:

[...]


Just for the fun of it, I implemented this as a template:

https://run.dlang.io/is/pXLndG


You're missing classes, AAs, and pointers (possibly function 
pointers and delegates as well).


I knew I was missing something. Fixed it, thanks

https://run.dlang.io/is/tZeZrP

Re: __has_side_effects

[Nicholas Wilson via Digitalmars-d]

On Sunday, 1 April 2018 at 04:11:37 UTC, Uknown wrote:
On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu 
wrote:

https://www.reddit.com/r/programming/comments/88aqsf/the_joy_of_max/

Discussion aside, I notice with pleasant surprise gcc has an 
introspection primitive we didn't think of: __is_constant that 
(I assume) yields true if the given expression has no side 
effects.


In D the primitive would be called e.g. __has_side_effects to 
avoid confusion with the "const" qualifier.


I wonder how difficult it would be to define 
__has_side_effects (it would apply to an alias) and how it can 
be put to good use.



Andrei


Just for the fun of it, I implemented this as a template:

https://run.dlang.io/is/pXLndG


You're missing classes, AAs, and pointers (possibly function 
pointers and delegates as well).

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu 
wrote:

https://www.reddit.com/r/programming/comments/88aqsf/the_joy_of_max/

Discussion aside, I notice with pleasant surprise gcc has an 
introspection primitive we didn't think of: __is_constant that 
(I assume) yields true if the given expression has no side 
effects.


In D the primitive would be called e.g. __has_side_effects to 
avoid confusion with the "const" qualifier.


I wonder how difficult it would be to define __has_side_effects 
(it would apply to an alias) and how it can be put to good use.



Andrei


Just for the fun of it, I implemented this as a template:

https://run.dlang.io/is/pXLndG

Re: auto-decoding

[Uknown via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 01:19:08 UTC, auto wrote:

What is auto decoding and why it is a problem?


Auto-decoding is essentially related to UTF representation of 
Unicode strings. In D, `char[]` and `string` represent UTF8 
strings, `wchar[]` and `wstring` represent UTF16 strings and 
`dchar[]` and `dstring` represent UTF32 strings. You need to know 
how UFT works in order to understand auto-decoding. Since in 
practice most code deals with UTF8 I'll explain wrt that. 
Essentially, the problem comes down to the fact that not all the 
Unicode characters are representable by 8 bit `char`s (for UTF8). 
Only the ASCII stuff is represented by the "normal" way. UTF8 
uses the fact that the first few buts in a char are never used in 
ASCII, to tell how many more `char`s ahead that character is 
encoded in. You can watch this video for a better 
understanding[0]. By default though, if one were to traverse a 
`char` looking for characters, they would get unexpected results 
with Unicode data


Auto-decoding tries to solve this by automatically applying the 
algorithm to decode the characters to Unicode "Code-Points". This 
is where my knowledge ends though. I'll give you pros and cons of 
auto-decoding.


Pros:
 * It makes Unicode string handeling much more easier for 
beginners.

 * Much less effort in general, it seems to "just work™"

Cons:
 * It makes string handling slow by default
 * It may be the wrong thing, since you may not want Unicode 
code-points, but graphemes instead.
 * Auto-decoding throws exceptions on reaching invalid 
code-points, so all string

handling code in general throws exceptions.

If you want to stop auto-decoding, you can use 
std.string.representation like this:


import std.string : representation;
auto no_decode = some_string.representation;

Now no_decode wont be auto-decoded, and you can use it in place 
of some_string. You can also use std.utf to decode by graphemes 
instead.


You should also read this blog post: 
https://jackstouffer.com/blog/d_auto_decoding_and_you.html


And this forum post: 
https://forum.dlang.org/post/eozguhavggchzzruz...@forum.dlang.org


[0]: https://www.youtube.com/watch?v=MijmeoH9LT4

Re: D compiles fast, right? Right??

[Walter Bright via Digitalmars-d]

On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote:

Could be faster.


It's been a fair amount of time since somebody has done profiling of dmd. It 
needs to be done. There's probably plenty of low hanging fruit. Speculating 
about why it is slow is pointless without data.

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Saturday, March 31, 2018 19:38:06 Andrei Alexandrescu via Digitalmars-d 
wrote:
> We need to have a simple recipe on how to define a canonical object.
> That would include requirements such as:
>
> * should work with mutable, const, immutable, and shared
> * the right way to define constructor(s)
> * the right way to define copying
> * the right way to define destructor(s)
>
> I've asked my student Razvan to document the behavior of this(this). His
> work:
>
> https://github.com/dlang/dmd/pull/8055
> https://github.com/dlang/dlang.org/pull/2281
> https://github.com/dlang/dlang.org/pull/2299
>
> ... reveals a puzzling array of behaviors. Sometimes the typechecking is
> wrong, too.
>
> I think it's very important for us to have a simple, correct, and
> canonical way of defining structs in the D language that work with the
> language features: qualifiers, pure, safe, and nogc.
>
> Once we have that, we can encapsulate desirable abstractions (such as
> @nogc safe collections that work in pure code), regardless of how
> difficult their implementations might be. It seems that currently
> this(this) does not allow us to do that.
>
> Eduard, another student I work with, has made steps toward a collections
> library that rant into difficulties:
>
> * @safe is achievable with relative ease
>
> * immutable and const are very difficult, but we have an attack
> (assuming copy construction gets taken care of)
>
> * @nogc is doable with a couple of conventions for allocators
>
> * pure is difficult
>
> * making them work together is very difficult
>
> We need to offer features, tools, and guidance toward creating simple
> encapsulated types that work well with D's own abstractions. Once we
> have that we can build libraries to work satisfactorily for any domain.
>
> I think the way to move forward is to deprecate this(this) entirely and
> create a DIP that allows people to define truly encapsulated structs.
> This is important, urgent, and of huge impact.
>
> I am looking for folks to assist me in creating a DIP for that. There
> will be a _lot_ of work involved, so don't take it lightly.

Another potential issue is whether any of this does or should relate to

https://github.com/dlang/DIPs/pull/109

and it's solution for hooking into to moves. I'm not at all sure that what
happens with that needs to be related to this at all, but it might.

- Jonathan M Davis

Re: D compiles fast, right? Right??

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 01, 2018 01:25:41 Jonathan Marler via Digitalmars-d wrote:
> On Saturday, 31 March 2018 at 21:37:13 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, March 31, 2018 08:28:31 Jonathan Marler via
> >
> > Digitalmars-d wrote:
> >> On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu
> >>
> >> wrote:
> >> > On 3/30/18 12:12 PM, Atila Neves wrote:
> >> >> Fast code fast, they said. It'll be fun, they said. Here's
> >> >> a D
> >> >>
> >> >> file:
> >> >>  import std.path;
> >> >>
> >> >> Yep, that's all there is to it. Let's compile it on my
> >> >>
> >> >> laptop:
> >> >>  /tmp % time dmd -c  foo.d
> >> >>  dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139
> >> >>
> >> >> total
> >> >
> >> > Could be faster.
> >> >
> >> >> That... doesn't seem too fast to me. But wait, there's more:
> >> >>  /tmp % time dmd -c -unittest foo.d
> >> >>  dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu
> >> >>
> >> >> 0.525 total
> >> >
> >> > Not fast. We need to make -unittest only affect the built
> >> > module. Even though it breaks certain uses of
> >> > __traits(getUnittests). No two ways about it. Who can work
> >> > on that?
> >> >
> >> > Andrei
> >>
> >> If you approve of the -unittest= approach then
> >> timotheecour has already offered to implement this.  It's
> >> pattern matching would work the same as -i and would also use
> >> the "implied standard exclusions" that -i uses, namely,
> >>
> >> -unittest=-std -unittest=-etc -unittest=-core
> >>
> >> This would mean that by default, just passing "-unittest"
> >> would exclude druntime/phobos just like "-i" by itself also
> >> does.
> >
> > And every time you used another library, you'd have the same
> > problem and have to add -unittest=- whatever for each and every
> > one of them, or you would have to use -unittest= with
> > everything from your application or library rather than using
> > -unittest. I really don't see how that scales well, and it's
> > way too manual and too easy to screw up. It might be a decent
> > idea for a workaround, but it's not a great solution.
> >
> > IMHO, this is really something that should be handled by the
> > compiler. It simply shouldn't be compiling in the unittest
> > blocks for modules that you're not compiling directly. And if
> > that's done right, then this whole problem goes away without
> > having to make sure that every project you work on is
> > configured correctly to avoid pulling in the unit tests from
> > everything that it depends on.
> >
> > And maybe figuring out what to do about __traits(getUnittests)
> > complicates things, but it seems like the fact that we're even
> > having this problem is due to a flaw in the design of D's unit
> > tests and that that should be fixed, not worked around.
> >
> > - Jonathan M Davis
>
> Let's make this conversation a bit more concrete, I'm not sure we
> are discussing the exact same thing.
>
> The proposed solution is to have -unittest mean "compile
> unittests for all 'compiled modules' according to the pattern
> rules".  The default pattern rule is to include all modules
> except druntime/phobos.
>
> Say you have two "packages" foo and bar that contain modules
> inside their respective directories.  With the proposed
> -unittest= this is the semantics you would get.
>
> dmd -unittest   foo/*.d bar/*.d # compiles unittests for
> foo/*.d and bar/*.d
> dmd -unittest=foo   foo/*.d bar/*.d # compiles unittests for
> foo/*.d
> dmd -unittest=bar   foo/*.d bar/*.d # compiles unittests for
> bar/*.d
> dmd -unittest=foo.x foo/*.d bar/*.d # compiles unittests for
> foo/x.d
> dmd -unittest=-bar  foo/*.d bar/*.d # compiles unittests for
> foo/*.d
>
> Note that the default behavior makes sense, but this mechanism
> also allows you more fine-graned control to limit unittesting to
> certain packages or modules.  This degree of control would be
> quite helpful to me, any of the previously listed use cases
> represent valid scenarios that I would like to be able to do.  Do
> you have another solution that would provide this functionality?
> I don't see any reason not to support these use cases.

My point is that this is not a good solution for the problem of dependencies
having their unit tests included in your project. That should simply not be
happening.

Discussions of ways to tell the compiler to enable unit tests for some
modules and not others within your own project are IMHO therefore a separate
issue. Now, as for the specific proposal trying to solve the issue of
running only certain unit tests in your project, I think that it's overly
complicated once you start having to deal with stuff like exclusions. I'd
argue for simply compiling the module or modules that you care about with
-unittest and that you not use -unittest when compiling the other modules.
All of this is going to have to be controlled by whatever build system
you're using anyway, since it really doesn't scale to keep calling the
compiler 

Re: D compiles fast, right? Right??

[Jonathan Marler via Digitalmars-d]

On Saturday, 31 March 2018 at 21:37:13 UTC, Jonathan M Davis 
wrote:
On Saturday, March 31, 2018 08:28:31 Jonathan Marler via 
Digitalmars-d wrote:

On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu

wrote:
> On 3/30/18 12:12 PM, Atila Neves wrote:
>> Fast code fast, they said. It'll be fun, they said. Here's 
>> a D

>>
>> file:
>>  import std.path;
>>
>> Yep, that's all there is to it. Let's compile it on my 
>> laptop:

>>  /tmp % time dmd -c  foo.d
>>  dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 
>> total

>
> Could be faster.
>
>> That... doesn't seem too fast to me. But wait, there's more:
>>  /tmp % time dmd -c -unittest foo.d
>>  dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu
>>
>> 0.525 total
>
> Not fast. We need to make -unittest only affect the built 
> module. Even though it breaks certain uses of 
> __traits(getUnittests). No two ways about it. Who can work 
> on that?

>
> Andrei

If you approve of the -unittest= approach then 
timotheecour has already offered to implement this.  It's 
pattern matching would work the same as -i and would also use 
the "implied standard exclusions" that -i uses, namely,


-unittest=-std -unittest=-etc -unittest=-core

This would mean that by default, just passing "-unittest" 
would exclude druntime/phobos just like "-i" by itself also 
does.


And every time you used another library, you'd have the same 
problem and have to add -unittest=- whatever for each and every 
one of them, or you would have to use -unittest= with 
everything from your application or library rather than using 
-unittest. I really don't see how that scales well, and it's 
way too manual and too easy to screw up. It might be a decent 
idea for a workaround, but it's not a great solution.


IMHO, this is really something that should be handled by the 
compiler. It simply shouldn't be compiling in the unittest 
blocks for modules that you're not compiling directly. And if 
that's done right, then this whole problem goes away without 
having to make sure that every project you work on is 
configured correctly to avoid pulling in the unit tests from 
everything that it depends on.


And maybe figuring out what to do about __traits(getUnittests) 
complicates things, but it seems like the fact that we're even 
having this problem is due to a flaw in the design of D's unit 
tests and that that should be fixed, not worked around.


- Jonathan M Davis


Let's make this conversation a bit more concrete, I'm not sure we 
are discussing the exact same thing.


The proposed solution is to have -unittest mean "compile 
unittests for all 'compiled modules' according to the pattern 
rules".  The default pattern rule is to include all modules 
except druntime/phobos.


Say you have two "packages" foo and bar that contain modules 
inside their respective directories.  With the proposed 
-unittest= this is the semantics you would get.


dmd -unittest   foo/*.d bar/*.d # compiles unittests for 
foo/*.d and bar/*.d
dmd -unittest=foo   foo/*.d bar/*.d # compiles unittests for 
foo/*.d
dmd -unittest=bar   foo/*.d bar/*.d # compiles unittests for 
bar/*.d
dmd -unittest=foo.x foo/*.d bar/*.d # compiles unittests for 
foo/x.d
dmd -unittest=-bar  foo/*.d bar/*.d # compiles unittests for 
foo/*.d


Note that the default behavior makes sense, but this mechanism 
also allows you more fine-graned control to limit unittesting to 
certain packages or modules.  This degree of control would be 
quite helpful to me, any of the previously listed use cases 
represent valid scenarios that I would like to be able to do.  Do 
you have another solution that would provide this functionality?  
I don't see any reason not to support these use cases.

Re: Deprecating this(this)

[rikki cattermole via Digitalmars-d]

On 01/04/2018 11:38 AM, Andrei Alexandrescu wrote:
We need to have a simple recipe on how to define a canonical object. 
That would include requirements such as:


* should work with mutable, const, immutable, and shared
* the right way to define constructor(s)
* the right way to define copying
* the right way to define destructor(s)


We will also need to make this consistent for classes.

***

So lets go back to the basics.

From the primordial goo that is My Own Little Language (MOLL heavily WIP):

__userType [Identifier:name] {
(Declaration|Definition)*
}

Is a value type, acts pretty much like struct.
Why do I not call it a struct? Because it shouldn't be used in user 
code. This exists only in mental models for D users currently.


So something like:

__userType Foo {
int x;

void __constructor(int x) {
this.x = x;
}

void __postblit() {
this.x = x+1;
}

void __deconstructor() {
// free?
}
}

Is comparable to D code of:

struct Foo {
int x;

this(this) {
this.x = x + 1;
}

~this() {
// free?
}
}

So what does a class look like?

__userType Foo {
enum __IS_CLASS = true;
static TypeInfo_Class TypeInfo = TypeInfo_Class(...);

static void*[][] __vtables = [
[, ...],
[, ...]
];

void*[] __vtable;
void* __ptr;

auto __cast(T)() if(T.__IS_CLASS) {
// ...
}
}

Why is this important? Because it shows that our current lifetime 
management strategies for ref counting with structs can be applied 
directly to classes.


***

At this point in time, lets look at how each qualifier is perceived:

mutable: default, good, everything else is a pain
const: library code and the author doesn't want you to go touchy
immutable: in binary only, quite yucky
shared: a message from the library author and not much else

I do not believe we can continue this conversation with the above 
perceptions.


First and foremost qualifiers are there to tell other developers (and 
yourself in the future) what you intend on doing with a given bit of 
memory. Now we do need a way to express head-const. Because it allows us 
to say that we personally can't modify a bit of memory but we can call a 
method that does (from it).


Good engineering requires us to consider psychology on these issues. To 
create a single unified view of this, will be tricky I think, but well 
worth it.

auto-decoding

[auto via Digitalmars-d-learn]

What is auto decoding and why it is a problem?

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/18 8:32 PM, H. S. Teoh wrote:

On Sat, Mar 31, 2018 at 07:38:06PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
[...]

Once we have that, we can encapsulate desirable abstractions (such as
@nogc safe collections that work in pure code), regardless of how
difficult their implementations might be. It seems that currently
this(this) does not allow us to do that.


What exactly is it about this(this) that blocks us from doing that?


See the updated docs. Too many bugs in design and implementation.


Removing this(this) is going to be a huge breaking change far bigger
than, say, removing autodecoding ever will be.


We're not removing it as much as evolving it: we define an alternate 
copying mechanism, and once that is in tip-top shape, we deprecate 
this(this).



A lot of us here have essentially given up on const except for a few
very narrow cases.  The transitive nature of const makes it extremely
difficult to work with in the general case, even though the simplest use
cases are workable.


Immutable is where it's at, in terms of usefulness. Const is a mere 
servant of it (and of mutable).



One of the biggest stumbling blocks is that whenever ranges are
involved, const is practically out of the question, because even though
it can be made to work for most cases, there will almost always be that
one pathological case where it's impossible / too hard to work around,
and that ruins it for everything else, so that it's much simpler to just
avoid it altogether.


Yah, the DIP might address that, too. Consider:

void fun(R)(R arr)
{
pragma(msg, typeof(arr));
}
void main()
{
immutable(int[]) arr = [ 1, 2, 3 ];
pragma(msg, typeof(arr));
fun(arr);
}

The program prints during compilation:

immutable(int[])
immutable(int)[]

Interesting! So the type of the array changes during template matching, 
which is an exception to the rule that templates always glom to the 
exact type passed.


This is a hack introduced in the compiler in response to the issues you 
mention. But we don't need hacks and special casing - we need a means 
for types to say "here's what needs to happen when a template parameter 
is matched against this type".


So the DIP would address manipulating qualified ranges as a perk.


The one nagging question I've been having about pure is: how much are we
actually taking advantage of the guarantees provided by pure?


Very little, but that doesn't matter. The problem is it's 
underspecified. So now it's like a vague threat - whenever we mess with 
fear somebody comes asking, but what about an aggressive compiler doing 
some unexpected optimizations based on such and such interpretation?


We need to lock pure down.


Andrei

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/18 9:01 PM, Jonathan M Davis wrote:

And as far as auto-decoding goes


Let's keep this about construction and not about auto-decoding. Thanks.

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Saturday, March 31, 2018 17:32:10 H. S. Teoh via Digitalmars-d wrote:
> On Sat, Mar 31, 2018 at 07:38:06PM -0400, Andrei Alexandrescu via
> Digitalmars-d wrote: [...]
>
> > Once we have that, we can encapsulate desirable abstractions (such as
> > @nogc safe collections that work in pure code), regardless of how
> > difficult their implementations might be. It seems that currently
> > this(this) does not allow us to do that.
>
> What exactly is it about this(this) that blocks us from doing that?
>
> Removing this(this) is going to be a huge breaking change far bigger
> than, say, removing autodecoding ever will be.

Well, as far const goes, you have the inherent problem that the object you
have in this(this) has already been initialized, and you can't mutate const.
I think that other attribute issues are mostly implementation issues.

And as far as auto-decoding goes, removing postblit constructors would
actually be far easier, because it's simply a matter of deprecating a
particular function. Some traits that check for postblits would have to be
adjusted, but all those really care about is that there's extra code beyond
the default copying code, and they could easily be made to work with both
postblits and whatever the new solution is at the same time until postblits
are actually gone.

Auto-decoding on the other hand, affects far more than just the functions in
std.range.primitives, and there is no clear deprecation path. So, while it
_might_ be true that deprecating postblits would break more code (and I'm
honestly not convinced that it would), postblit constructors would actually
have a clean deprecation path. So, while it breaks code, it does so in a way
that can easily be managed, whereas the removal of auto-decoding is not
straightforward at all. It could be done by just flipping the switch
so-to-speak, but AFAIK, no one has yet presented a workable deprecation
path. And ultimately, I think that _that_ is what's preventing us from
fixing auto-decoding. If a clean deprecation path were found, then we could
discuss whether the resulting breakage would be worth it, but without a
clean deprecation path, I don't see how we could ever do it.

Also, unless we can fix postblit constructors (and the evidence thus far is
that if we can, it's way too complicated - e.g. Kenji's attempt several
years ago was rejected because it was way too complicated), if we don't
switch to a differnt solution, we're talking about permanently not
supporting copying const types that require user-defined copying.

> A lot of us here have essentially given up on const except for a few
> very narrow cases.  The transitive nature of const makes it extremely
> difficult to work with in the general case, even though the simplest use
> cases are workable.
>
> One of the biggest stumbling blocks is that whenever ranges are
> involved, const is practically out of the question, because even though
> it can be made to work for most cases, there will almost always be that
> one pathological case where it's impossible / too hard to work around,
> and that ruins it for everything else, so that it's much simpler to just
> avoid it altogether.

I don't think that it's even the case that it can be made to work in most
cases - or if it can, it involves a lot of static ifs. The range API does
not require const for _anything_ (and really can't due to how restricted
const is), so _no_ generic range-based code can assume that even something
like length or empty can be called if the range is const or inout. As such,
the only ranges that can mark anything with const are ones that either
aren't generic or which have a bunch of static ifs presenting const and
non-const versions depending on the template arguments, and IMHO, that's
just not workable. I've done it before, and it's a mess. As such, ranges and
const really don't work together at all. const really only works when you're
dealing with a very constrainted set of types where you can actually
guarantee that they work with const.

> > * pure is difficult
>
> [...]
>
> The one nagging question I've been having about pure is: how much are we
> actually taking advantage of the guarantees provided by pure?  We have
> developed very clever ways of extending the traditional definition of
> pure and invented creative ways of making more things pure, which is all
> great.  But AFAIK the only place where it's actually taken advantage of
> is to elide some redundant function calls inside a single expression.
> And perhaps infer uniqueness in some cases for implicit casting to
> immutable.
>
> While these are indisputably useful, they seem so far to be only
> relatively minor benefits.  If pure is indeed so difficult to support
> generically, it begs the question, is it worth the effort just to gain
> these niggling benefits?  Whatever happened to larger-scale benefits
> conferred by purity?

Honestly, I think that the main benefit of pure is that if you know that a
function is pure, you know that it 

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/18 8:25 PM, Jonathan M Davis wrote:

So, is the idea then that we'd switch to copy constructors?


Something like that. We'll need to define them carefully to obey safety 
and purity.

Re: __has_side_effects

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/18 8:35 PM, Nicholas Wilson wrote:

On Saturday, 31 March 2018 at 20:44:13 UTC, Andrei Alexandrescu wrote:
Yah, only strongly pure functions would qualify. Indeed that's easy 
for the compiler to figure - so I'm thinking pragma(isStronglyPure, 
expression) would be easy to define.


What would be some good uses of this?


Andrei


Surely you mean __traits(isStronglyPure, expression)?


Affirmative, thx for the correction.

Re: __has_side_effects

[Nicholas Wilson via Digitalmars-d]

On Saturday, 31 March 2018 at 20:44:13 UTC, Andrei Alexandrescu 
wrote:
Yah, only strongly pure functions would qualify. Indeed that's 
easy for the compiler to figure - so I'm thinking 
pragma(isStronglyPure, expression) would be easy to define.


What would be some good uses of this?


Andrei


Surely you mean __traits(isStronglyPure, expression)?

[Issue 13724] std.datetime.timeIt

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13724

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #9 from Jonathan M Davis  ---
I'm not at all convinced that this is worth adding, but if I were to add
something like this, I would probably make it use a callback that gave the
Duration so that it would be simple to do something like turn

auto foo = doSomething(args);

into

auto foo = timeIt!(a => writefln("doSomething: %s, a))(doSomething(args));

or

void printIt(Duration d, string file = __FILE__, size_t line = __LINE__)
{
writefln("%s(%s): %s", file, line, d);
}

auto foo = timeIt!printIt(doSomething(args));

But then again, the only reason I see to have a function like this would be to
do something like print or log the results of a particular run. It certainly
isn't appropriate for benchmarking.

--

Re: Deprecating this(this)

[H. S. Teoh via Digitalmars-d]

On Sat, Mar 31, 2018 at 07:38:06PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
[...]
> Once we have that, we can encapsulate desirable abstractions (such as
> @nogc safe collections that work in pure code), regardless of how
> difficult their implementations might be. It seems that currently
> this(this) does not allow us to do that.

What exactly is it about this(this) that blocks us from doing that?

Removing this(this) is going to be a huge breaking change far bigger
than, say, removing autodecoding ever will be.


> Eduard, another student I work with, has made steps toward a
> collections library that rant into difficulties:
> 
> * @safe is achievable with relative ease
> 
> * immutable and const are very difficult, but we have an attack
> (assuming copy construction gets taken care of)

A lot of us here have essentially given up on const except for a few
very narrow cases.  The transitive nature of const makes it extremely
difficult to work with in the general case, even though the simplest use
cases are workable.

One of the biggest stumbling blocks is that whenever ranges are
involved, const is practically out of the question, because even though
it can be made to work for most cases, there will almost always be that
one pathological case where it's impossible / too hard to work around,
and that ruins it for everything else, so that it's much simpler to just
avoid it altogether.

Also, as far as containers are concerned, the lack of a standard way to
construct head-mutable / tail-const types that works analogously with
built-in arrays makes it very difficult to write generic containers that
work well with const/immutable.  It's not too hard to make it work for
specific types, but very difficult to write a truly *generic* container
that can be deployed in all situations where const/immutable are
involved.


[...]
> * pure is difficult
[...]

The one nagging question I've been having about pure is: how much are we
actually taking advantage of the guarantees provided by pure?  We have
developed very clever ways of extending the traditional definition of
pure and invented creative ways of making more things pure, which is all
great.  But AFAIK the only place where it's actually taken advantage of
is to elide some redundant function calls inside a single expression.
And perhaps infer uniqueness in some cases for implicit casting to
immutable.

While these are indisputably useful, they seem so far to be only
relatively minor benefits.  If pure is indeed so difficult to support
generically, it begs the question, is it worth the effort just to gain
these niggling benefits?  Whatever happened to larger-scale benefits
conferred by purity?


T

-- 
Computers aren't intelligent; they only think they are.

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Saturday, March 31, 2018 19:38:06 Andrei Alexandrescu via Digitalmars-d 
wrote:
> We need to have a simple recipe on how to define a canonical object.
> That would include requirements such as:
>
> * should work with mutable, const, immutable, and shared
> * the right way to define constructor(s)
> * the right way to define copying
> * the right way to define destructor(s)
>
> I've asked my student Razvan to document the behavior of this(this). His
> work:
>
> https://github.com/dlang/dmd/pull/8055
> https://github.com/dlang/dlang.org/pull/2281
> https://github.com/dlang/dlang.org/pull/2299
>
> ... reveals a puzzling array of behaviors. Sometimes the typechecking is
> wrong, too.
>
> I think it's very important for us to have a simple, correct, and
> canonical way of defining structs in the D language that work with the
> language features: qualifiers, pure, safe, and nogc.
>
> Once we have that, we can encapsulate desirable abstractions (such as
> @nogc safe collections that work in pure code), regardless of how
> difficult their implementations might be. It seems that currently
> this(this) does not allow us to do that.
>
> Eduard, another student I work with, has made steps toward a collections
> library that rant into difficulties:
>
> * @safe is achievable with relative ease
>
> * immutable and const are very difficult, but we have an attack
> (assuming copy construction gets taken care of)
>
> * @nogc is doable with a couple of conventions for allocators
>
> * pure is difficult
>
> * making them work together is very difficult
>
> We need to offer features, tools, and guidance toward creating simple
> encapsulated types that work well with D's own abstractions. Once we
> have that we can build libraries to work satisfactorily for any domain.
>
> I think the way to move forward is to deprecate this(this) entirely and
> create a DIP that allows people to define truly encapsulated structs.
> This is important, urgent, and of huge impact.
>
> I am looking for folks to assist me in creating a DIP for that. There
> will be a _lot_ of work involved, so don't take it lightly.

So, is the idea then that we'd switch to copy constructors?

- Jonathan M Davis

Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

We need to have a simple recipe on how to define a canonical object. 
That would include requirements such as:


* should work with mutable, const, immutable, and shared
* the right way to define constructor(s)
* the right way to define copying
* the right way to define destructor(s)

I've asked my student Razvan to document the behavior of this(this). His 
work:


https://github.com/dlang/dmd/pull/8055
https://github.com/dlang/dlang.org/pull/2281
https://github.com/dlang/dlang.org/pull/2299

... reveals a puzzling array of behaviors. Sometimes the typechecking is 
wrong, too.


I think it's very important for us to have a simple, correct, and 
canonical way of defining structs in the D language that work with the 
language features: qualifiers, pure, safe, and nogc.


Once we have that, we can encapsulate desirable abstractions (such as 
@nogc safe collections that work in pure code), regardless of how 
difficult their implementations might be. It seems that currently 
this(this) does not allow us to do that.


Eduard, another student I work with, has made steps toward a collections 
library that rant into difficulties:


* @safe is achievable with relative ease

* immutable and const are very difficult, but we have an attack 
(assuming copy construction gets taken care of)


* @nogc is doable with a couple of conventions for allocators

* pure is difficult

* making them work together is very difficult

We need to offer features, tools, and guidance toward creating simple 
encapsulated types that work well with D's own abstractions. Once we 
have that we can build libraries to work satisfactorily for any domain.


I think the way to move forward is to deprecate this(this) entirely and 
create a DIP that allows people to define truly encapsulated structs. 
This is important, urgent, and of huge impact.


I am looking for folks to assist me in creating a DIP for that. There 
will be a _lot_ of work involved, so don't take it lightly.



Thanks,

Andrei

Re: D compiles fast, right? Right??

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/18 5:37 PM, Jonathan M Davis wrote:

And every time you used another library, you'd have the same problem and
have to add -unittest=- whatever for each and every one of them, or you
would have to use -unittest= with everything from your application or
library rather than using -unittest. I really don't see how that scales
well, and it's way too manual and too easy to screw up. It might be a decent
idea for a workaround, but it's not a great solution.


Nod. We really need to get to the point where the application of 
unittest is modular.

[Issue 15710] Replacement for std.utf.validate which does not throw

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15710

--- Comment #2 from Jonathan M Davis  ---
Well having isValidUTF rather than validate would just make it so that you can
use an if-else block instead of a try-catch. It wouldn't really clean that code
up much.

If you really want to clean up what you're doing in that example, you need to
use byCodeUnit or byUTF, which use the replacement character. In that case, you
wouldn't need to check for valid Unicode. If you want a string out the other 
side instead of a range of code units or code points, you then just call
to!string or toUTF8 on it. e.g.

auto codeUnits = str.byCodeUnit();

or

auto dchars = str.byDchar(); // byUTF!dchar

or

str = str.byCodeUnit().to!string();

Now, if you want a string and don't want to allocate a new string if the string
is valid, then you'd need to check whether the string is valid Unicode, but in
that case you still don't need anything as complicated as what you wrote for
toValidUTF. You'd just need something like

try
str.validate();
catch(UnicodeException)
str = str.byCodeUnit().to!string();

and if we had isValidUTF, then you'd have

if(!str.isValidUTF())
str = str.byCodeUnit().to!string();

So, while isValidUTF would help, it's mostly just getting rid of an unnecessary
exception, which does clean up the code in this case, but not drastically. It's
byCodeUnit or byUTF that really clean things up here.

Now, as for adding isValidUTF, I have a PR for it in the PR queue, and Andrei
approved the symbol, but he rejected the implementation. He basically wanted me
to completely redesign how decode works internally and that the superficial
changes I had made to make it work with isValidUTF were too ugly to live. So,
at some point here, I need to go back and figure out how to rework all that
again, which is not going to be pretty.

--

Re: D compiles fast, right? Right??

[Jonathan M Davis via Digitalmars-d]

On Saturday, March 31, 2018 08:28:31 Jonathan Marler via Digitalmars-d 
wrote:
> On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu
>
> wrote:
> > On 3/30/18 12:12 PM, Atila Neves wrote:
> >> Fast code fast, they said. It'll be fun, they said. Here's a D
> >>
> >> file:
> >>  import std.path;
> >>
> >> Yep, that's all there is to it. Let's compile it on my laptop:
> >>  /tmp % time dmd -c  foo.d
> >>  dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total
> >
> > Could be faster.
> >
> >> That... doesn't seem too fast to me. But wait, there's more:
> >>  /tmp % time dmd -c -unittest foo.d
> >>  dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu
> >>
> >> 0.525 total
> >
> > Not fast. We need to make -unittest only affect the built
> > module. Even though it breaks certain uses of
> > __traits(getUnittests). No two ways about it. Who can work on
> > that?
> >
> > Andrei
>
> If you approve of the -unittest= approach then
> timotheecour has already offered to implement this.  It's pattern
> matching would work the same as -i and would also use the
> "implied standard exclusions" that -i uses, namely,
>
> -unittest=-std -unittest=-etc -unittest=-core
>
> This would mean that by default, just passing "-unittest" would
> exclude druntime/phobos just like "-i" by itself also does.

And every time you used another library, you'd have the same problem and
have to add -unittest=- whatever for each and every one of them, or you
would have to use -unittest= with everything from your application or
library rather than using -unittest. I really don't see how that scales
well, and it's way too manual and too easy to screw up. It might be a decent
idea for a workaround, but it's not a great solution.

IMHO, this is really something that should be handled by the compiler. It
simply shouldn't be compiling in the unittest blocks for modules that you're
not compiling directly. And if that's done right, then this whole problem
goes away without having to make sure that every project you work on is
configured correctly to avoid pulling in the unit tests from everything that
it depends on.

And maybe figuring out what to do about __traits(getUnittests) complicates
things, but it seems like the fact that we're even having this problem is
due to a flaw in the design of D's unit tests and that that should be fixed,
not worked around.

- Jonathan M Davis

Re: Need a fancy domain for your project? .dub.pm has you covered!

[bauss via Digitalmars-d-announce]

On Thursday, 23 February 2017 at 14:16:35 UTC, Seb wrote:

Hey all,

As I own dub.pm since a year and it hasn't been used much, I 
have just configured automatic sub-domain rewriting, s.t. 
everyone can have nice and fancy URLs. All sub-domains get 
redirected to their respective DUB package page, so now you can 
browse e.g.


[...]


This is pretty cool.

diamondmvc.org has been launched - Also release of Diamond MVC v2.8.5

[bauss via Digitalmars-d-announce]

I'm happy to announce that Diamond finally has its own website, 
that is hosted as a Diamond project, instead of a Github-page!


It can be found here: http://diamondmvc.org/

The website is open-source and can be used as a reference on how 
to use Diamond, although it doesn't use a lot of "advanced" 
features as of now.


The website project can be found here: 
https://github.com/DiamondMVC/Diamond-website


On top of that v2.8.5 has been released which comes with some 
task functionality.


Since last announcement v2.8.1 the following has also been added:

* Special placeholders for i18n
* File uploading improvements

Thanks to everyone who has helped Diamond getting where it is, 
whether it has been through contributions to Diamond's 
dependencies, the d programming language or anything else!

Re: Need a fancy domain for your project? .dub.pm has you covered!

[Seb via Digitalmars-d-announce]

On Thursday, 23 February 2017 at 14:16:35 UTC, Seb wrote:

Hey all,

As I own dub.pm since a year and it hasn't been used much, I 
have just configured automatic sub-domain rewriting, s.t. 
everyone can have nice and fancy URLs. All sub-domains get 
redirected to their respective DUB package page, so now you can 
browse e.g.


eventcore.dub.pm
vibe-core.dub.pm
...


In the future the package pages might be served directly 
without redirects (vote for this behavior at [1])


If you don't like the layout, design or features of the 
dub-registry, it's just a PR away [2]!


Last, but not least a reminder that if you need a 
.dlang.io or 
.dlang.rocks subdomain for your project, I 
am happy to set the DNS for you.

Just give me a short ping [3].

Cheers and happy hacking!

Seb

[1] https://github.com/dlang/dub/issues/781
[2] https://github.com/dlang/dub-registry
[3] https://seb.wilzba.ch/contact


As Letsencrypt now supports SSL wildcards, *.dub.pm are now all 
accessible via SSL:


https://mir.dub.pm
https://container.dub.pm

Re: Fast GC allocation of many small objects

[Per Nordlöw via Digitalmars-d-learn]

On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote:

 auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);


Thanks!


Turns out that Region allocator wasn't fully qualified:

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

This will make it possible to allocate with it in pure code :)

Re: __has_side_effects

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/18 4:01 PM, Simen Kjærås wrote:

On Saturday, 31 March 2018 at 19:18:24 UTC, Shachar Shemesh wrote:

struct S {
  int a;

  void func(int b) pure {
    // For some strange reason, this is not considered a pure violation.
    a+=b;
  }
}


It's the exact equivalent of this code:

void func(ref S s, int b) pure {
     S.a += b;
}

And that code is perfectly pure accordion to D rules - it does not 
modify any data not reachable through its arguments.


Yah, only strongly pure functions would qualify. Indeed that's easy for 
the compiler to figure - so I'm thinking pragma(isStronglyPure, 
expression) would be easy to define.


What would be some good uses of this?


Andrei

[Issue 14562] Support BigInt function std.range.repeat and other functions of Phobos

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14562

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #3 from Simen Kjaeraas  ---
There are extremely few cases where using a value above 2^63 for the repeat
count is sensible. For the remaining 100% of cases, there's
https://dlang.org/phobos/std_bigint#.BigInt.toLong.

--

Re: Fast GC allocation of many small objects

[Per Nordlöw via Digitalmars-d-learn]

On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu 
wrote:

Hello,

You can try the following:
struct Node
{
char[64] arr;
}

 enum numNodes = 100_000_000;
 void[] buf = GCAllocator.instance.allocate(numNodes * 
Node.sizeof);

 auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);


Thanks!

Is a `minAlign` of 16 recommended over 8 when allocating classes 
or arrays?

Re: __has_side_effects

[Simen Kjærås via Digitalmars-d]

On Saturday, 31 March 2018 at 19:18:24 UTC, Shachar Shemesh wrote:

struct S {
  int a;

  void func(int b) pure {
// For some strange reason, this is not considered a pure 
violation.

a+=b;
  }
}


It's the exact equivalent of this code:

void func(ref S s, int b) pure {
S.a += b;
}

And that code is perfectly pure accordion to D rules - it does 
not modify any data not reachable through its arguments.


--
  Simen

About the dub-registry

[Seb via Digitalmars-d]

So a lot of people are complaining about the dub-registry, but 
(as usual) not many people actually work on it.


Let me make it simple for you - this time only your UX feedback 
is needed!
There are a few PRs in the queue that could really have someone 
looking at the proposed design changes:


https://github.com/dlang/dub-registry/pull/302 (more tabs)
https://github.com/dlang/dub-registry/pull/303 (front page top10 
listing)


Oh no setup is required - you can preview these PRs directly in 
your browser, e.g.


https://deploy-preview-303--dub-registry.netlify.com/



If you are more technically skilled, you can also hack with the 
registry.

Spoiler: it's written in D + Vibe.d:

https://github.com/dlang/dub-registry

Or review PRs in the queue there:

https://github.com/dlang/dub-registry/pulls

And as always you can share ideas / thoughts etc. here:

https://github.com/dlang/dub-registry/issues

Re: Fast GC allocation of many small objects

[Seb via Digitalmars-d-learn]

On Saturday, 31 March 2018 at 19:38:31 UTC, Per Nordlöw wrote:

On Saturday, 31 March 2018 at 19:31:37 UTC, Rubn wrote:
Be willing to change your code, the allocator can change at 
any point. What you implement today may not work tomorrow, 
what you fix to work for tomorrow may not end up working the 
next day (in terms of releases). That really should be 
something that is mentioned when you suggest using an 
experimential feature, there's no guarantees at all. It might 
not even get put into phobos. If your project is going to be 
used over the course of a year or more than maybe you 
shouldn't use it.


Ok, thanks for the point.

Is the dub package stdx-allocator [1] a better alternative in 
this regard?


[1] https://github.com/dlang-community/stdx-allocator


Yep, that's why it was created. It's a snapshot of

https://docarchives.dlang.io/v2.077.0/phobos/std_experimental_allocator.html

It might be updated later, but with dub it's really easy to lock 
it to a specific version - which you can't when upgrading the 
compiler.

Re: Fast GC allocation of many small objects

[Per Nordlöw via Digitalmars-d-learn]

On Saturday, 31 March 2018 at 19:31:37 UTC, Rubn wrote:
Be willing to change your code, the allocator can change at any 
point. What you implement today may not work tomorrow, what you 
fix to work for tomorrow may not end up working the next day 
(in terms of releases). That really should be something that is 
mentioned when you suggest using an experimential feature, 
there's no guarantees at all. It might not even get put into 
phobos. If your project is going to be used over the course of 
a year or more than maybe you shouldn't use it.


Ok, thanks for the point.

Is the dub package stdx-allocator [1] a better alternative in 
this regard?


[1] https://github.com/dlang-community/stdx-allocator

[Issue 17183] Improve std.algorithm.mutate.remove documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17183

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
>  Moving some of the details to a static if internally can yield improvements 
> in all three doc locations.

We have done this now too:
https://dlang.org/phobos/std_algorithm_mutation.html#.remove

There's also:

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

which tries to address the actual API problems of remove

--

Re: Fast GC allocation of many small objects

[Rubn via Digitalmars-d-learn]

On Friday, 30 March 2018 at 20:46:43 UTC, Per Nordlöw wrote:
On Friday, 30 March 2018 at 20:38:35 UTC, rikki cattermole 
wrote:
Use a custom allocator (that could be backed by the GC) using 
std.experimental.allocators :)


https://dlang.org/phobos/std_experimental_allocator.html

is massive.

I guess I should allocate my nodes using

auto node = theAllocator.make!StrNode("alpha");

Could someone please give a working example of a GC-backed 
`theAllocator` suitable for my allocation pattern?


Be willing to change your code, the allocator can change at any 
point. What you implement today may not work tomorrow, what you 
fix to work for tomorrow may not end up working the next day (in 
terms of releases). That really should be something that is 
mentioned when you suggest using an experimential feature, 
there's no guarantees at all. It might not even get put into 
phobos. If your project is going to be used over the course of a 
year or more than maybe you shouldn't use it.

[Issue 17137] std.stdio.readln should provide an OutputRange overload

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17137

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 17127] bad example code for std.concurrency.Generator

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17127

--- Comment #5 from Seb  ---
https://github.com/dlang/phobos/pull/5873 is the only bit left, but that's
currently failing on 32-bit testers.

--

[Issue 17047] std.algorithm.iteration.splitter should propagate bidirectionality

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17047

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #1 from Seb  ---
https://github.com/dlang/phobos/pull/6150

> Making splitter a bidirectional range fundamentally broken - at least if the 
> delimiter has more than one element. Think about something like

---
auto result = "***".splitter("**"); // odd number in the string being
split, even number in the delimeter
---

> The range is not going to have the same elements if it's iterated from the 
> back. It will end up being split differently.

--

[Issue 17046] std.algorithm.iteration.splitter should work with mere ForwardRanges

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17046

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 18701] New: std.conv.emplaceRef should be made publicly available

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18701

  Issue ID: 18701
   Summary: std.conv.emplaceRef should be made publicly available
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: bootcamp, safe
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

std.conv.emplaceRef is Phobos's internal @safe version of emplace.
Like `formattedRead`, emplace should be made @safe if no pointers are used.

Motivation:

No need for these hacks anymore - just `emplace!SafeClass(buf, 5)`

---
auto support = (() @trusted => cast(SafeClass)(buf.ptr))();
auto safeClass = emplace!SafeClass(support, 5);
---

--

[Issue 17030] Specialize range functions for isSortedRange

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17030

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17026] std.conv.emplace could be @safe if the constructor is so

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17026

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
It's now fixed with (but only with -dip1000)

--

Re: __has_side_effects

[Shachar Shemesh via Digitalmars-d]

On 30/03/18 23:35, Stefan Koch wrote:

On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu wrote:

https://www.reddit.com/r/programming/comments/88aqsf/the_joy_of_max/

Discussion aside, I notice with pleasant surprise gcc has an 
introspection primitive we didn't think of: __is_constant that (I 
assume) yields true if the given expression has no side effects.


In D the primitive would be called e.g. __has_side_effects to avoid 
confusion with the "const" qualifier.


I wonder how difficult it would be to define __has_side_effects (it 
would apply to an alias) and how it can be put to good use.



Andrei


It's actually quite easy.
make a function literal annotated with pure and call your function, if 
that returns the function had no side effects.
if something is constant you can determine by using at in ctfe context, 
if that function call does not compile then it is not a constant.


That would work in C++. It does not work with D. D is willing to call 
functions that have side effects "pure".


struct S {
  int a;

  void func(int b) pure {
// For some strange reason, this is not considered a pure violation.
a+=b;
  }
}

[Issue 17024] check Phobos for convenience wrapper for templated struct

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17024

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17020] std.parallelism.taskpool amap should accept lambdas

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17020

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17019] std.algorithm.iteration.each should be usable with parallel

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17019

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 17018] Push std.experimental.xml

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17018

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
experimental.xml is now at:

https://github.com/dlang-community/experimental.xml

Though dxml has been recently started and might become a replacement:

https://github.com/jmdavis/dxml

--

[Issue 16614] [META] Each artifact in the standard library should have a meaningful example

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16614

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
This is now being tracked by https://github.com/dlang/phobos/projects/1 - we
are almost half-way through the remaining module blacklist :)

--

[Issue 15972] range of chars doesn't work with joiner with literal delimiters

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15972

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---

> What I have in mind:
> 1. Move autodecoding algorithms to undead.
> 2. Remove autodecoding from algorithms.
> 3. Have dfix rewrite std.algorithm to undead.algorithm

How would that work in practice?

std.algorithm is highly templated and the big issue are the auto-decoding
primitives in std.range.
We can't remove them easily nor even version them out (see e.g.
https://github.com/dlang/phobos/pull/5513) and no one seems to have found a
good transition path so far.

For now .byCodeUnit is the only available workaround and maybe eventually
RCString gets a thing.

--

[Issue 15969] makeNrray - allocate + dispose multi-dimensional array

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15969

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---


https://dlang.org/phobos/std_experimental_allocator.html#makeMultidimensionalArray
https://dlang.org/phobos/std_experimental_allocator.html#disposeMultidimensionalArray

--

[Issue 15971] BigInt ctor should accept forward ranges

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15971

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15750] net/isemail uses lots of redundant helper methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15750

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15732] std.function partial does not work with function / delegate references

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15732

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15710] Replacement for std.utf.validate which does not throw

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15710

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
Yeah, I would be really cool if I don't have to do such ugly hacks when I just
want to handle invalid UTF.

---
private string toValidUTF(string s)
{
import std.algorithm.iteration : map;
import std.range : iota;
import std.utf;
return s.representation.length
.iota
.map!(i => s.decode!(UseReplacementDchar.yes)(i))
.toUTF8;
}

try {
outStream.validate;
} catch (UTFException) {
outStream = outStream.toValidUTF;
}
---

--

[Issue 15645] Tuple.slice() causes memory corruption.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15645

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #6 from Seb  ---
This was fixed by https://github.com/dlang/phobos/pull/5342 (or well at least
this PR prevents the unsafe usage).

--

[Issue 15294] receiveTimeout with negative value asserts

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15294

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
This has been fixed in 2.072:

https://run.dlang.io/is/FlTlZj

--

[Issue 15285] Range-ified functions for std.string

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15285

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15227] std.format undocumented grammar

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15227

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15147] std.random.uniform return value depends on integer size

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15147

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
I just ran into this when trying to add more/better public examples for
std.random (https://github.com/dlang/phobos/pull/6393).

Normally, examples can be done by seeding the RNG and thus _knowing_ the
sequence of the PRNG.
The current behavior is really nasty.

--

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Chris Katko via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast


My only question would be if you think what is currently posted 
is objective.

[Issue 14647] std.random line 3015 heisenbug with FreeBSD_32

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14647

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #4 from Seb  ---
I haven't seen this one in the last two years, so I'm assuming that it has been
fixed. Closing.

--

[Issue 14562] Support BigInt function std.range.repeat and other functions of Phobos

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14562

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 14553] The return types of std.array.array for narrow strings conflicts with its documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14553

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 14543] std.algorithm.searching.until does not handle range sentinels nicely

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14543

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp

--

[Issue 14312] std.random unittest has intermittent failure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14312

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
I haven't seen this in the last two years, so I assume its fixed.

--

Re: Fast GC allocation of many small objects

[Rémy Mouëza via Digitalmars-d-learn]

On Saturday, 31 March 2018 at 09:10:13 UTC, Boris-Barboris wrote:

On Friday, 30 March 2018 at 20:31:35 UTC, Per Nordlöw wrote:
Is there a faster way of allocating many small class objects 
such as...


maybe something like this:

import std.conv: to;
import std.stdio;

class Node {}

class StrNode : Node
{
string value;
}

void main()
{
writeln(StrNode.classinfo.name);// onlineapp.StrNode
size_t il = StrNode.classinfo.m_init.length;
writeln(il); // 32
void[] backBuf = new void[il * 1000];
StrNode[] nodes = new StrNode[1000];
for (int i = 0; i < 1000; i++)
{
backBuf[i * il .. (i+1) * il] = 
StrNode.classinfo.m_init;

nodes[i] = cast(StrNode) [i * il];
nodes[i].value = i.to!string;
}
foreach (n; nodes[995..$])
writeln(n.classinfo.name, " ", n.value);  
// prints onlineapp.StrNode 995-999
}


I would have used std.conv.emplace:

import std.stdio;
import std.conv : emplace, to;

class Node {
string value;

this (long n) {
this.value = n.to!string;
}

override string toString () {
return "Node (value: " ~ value ~ ")";
}
}

void main (string [] args) {

/* size_t size = Node.sizeof; */
size_t size = Node.classinfo.m_init.length;
void [] memory = new void [size * 1000];
Node [] nodes  = new Node [1000];

foreach (i, node; nodes) {
void [] buf = memory [i * size.. i * size + size];
nodes [i] = emplace!Node (buf, i);
}
nodes [0]  .writeln;
nodes [$-1].writeln;
}

[Issue 13965] More handy schwartzSort

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13965

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86 |All
 OS|Windows |All

--

[Issue 13893] "rawRead must take a non-empty buffer"

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13893

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

Re: std.variant Is Everything Cool About D

[Pjotr Prins via Digitalmars-d-announce]

Great blog. Thanks.

[Issue 13924] Deprecate std.random.uniformDistribution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13924

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 13916] Nested std.concurrency.receive doesn't work correctly

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13916

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
So I experimented with removing the message from the list before the handler is
called, but I always get a LinkTerminated Exception which comes from the child
being terminated.
The child is in a while(true) loop, so it shouldn't get terminated, but for
some reason now its module deconstructor is now immediately called :/


diff --git a/std/concurrency.d b/std/concurrency.d
index 0e1b505bc..1c426bcc0 100644
--- a/std/concurrency.d
+++ b/std/concurrency.d
@@ -1974,8 +1980,9 @@ private
 enum timedWait = false;
 }

-bool onStandardMsg(ref Message msg)
+bool onStandardMsg(ref Message msg, void delegate() beforeSuccess
= (){})
 {
 foreach (i, t; Ops)
 {
 alias Args = Parameters!(t);
@@ -1985,10 +1992,13 @@ private
 {
 static if (is(ReturnType!(t) == bool))
 {
-return msg.map(op);
+beforeSuccess();
+auto b = msg.map(op);
+return b;
 }
 else
 {
+beforeSuccess();
 msg.map(op);
 return true;
 }
@@ -2043,6 +2053,8 @@ private
 {
 for (auto range = list[]; !range.empty;)
 {
+import std.stdio;
+writefln("range: %s", range.front);
 // Only the message handler will throw, so if this occurs
 // we can be certain that the message was handled.
 scope (failure)
@@ -2071,11 +2083,9 @@ private
 }
 else
 {
-if (onStandardMsg(range.front))
-{
-list.removeAt(range);
+if (onStandardMsg(range.front, (){
list.removeAt(range); }))
 return true;
-}
+
 range.popFront();
 continue;
 }
```

--

Re: #dbugfix Issue 16486 200$

[Timon Gehr via Digitalmars-d]

On 31.03.2018 18:34, Simen Kjærås wrote:

On Saturday, 31 March 2018 at 13:34:18 UTC, Kagamin wrote:

On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:
Ah that is an interesting bug which further demonstrates that 
templates are a tricky thing :)
Basically you cannot _generally_ proof that one template just 
forwards to another.

Therefore you have to create separate types.
And since you create separate types the alias is not an alias but a 
separate template.
Solving this may be possible for special cases but in the general 
case is infeasible.


If a template is used as a type it should be resolved to a type, no? 
And template resolves to a type in a straightforward way. Where does 
it fail? Judging by the error message "cannot deduce function from 
argument types !()(TestType!int)" it does successfully resolve alias 
to a type.


You're starting in the wrong end - the type cannot yet be considered, 
since the compiler doesn't know the correct arguments to TestAlias. 
Given this code:


struct S(T...) {}
alias SS(T...) = S!(T, int);

void foo(T)(SS!T arg) {}

unittest {
     foo(SS!string());
}

The error message is "template foo cannot deduce function from argument 
types !()(S!(string, int)), candidates are: foo(T)(SS!T arg)".

...

If the compiler were to do something other than give up, we would need 
some algorithm to define what it should try, and in which order.


It should simply run a limited semantic analysis on the function 
parameters before matching.


void foo(T)(SS!T arg) -> void foo(T)(S!(T, int) arg)

To support Ilya's use case, it suffices to expand unconstrained alias 
templates.

Re: #dbugfix Issue 16486 200$

[Simen Kjærås via Digitalmars-d]

On Saturday, 31 March 2018 at 13:34:18 UTC, Kagamin wrote:

On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:
Ah that is an interesting bug which further demonstrates that 
templates are a tricky thing :)
Basically you cannot _generally_ proof that one template just 
forwards to another.

Therefore you have to create separate types.
And since you create separate types the alias is not an alias 
but a separate template.
Solving this may be possible for special cases but in the 
general case is infeasible.


If a template is used as a type it should be resolved to a 
type, no? And template resolves to a type in a straightforward 
way. Where does it fail? Judging by the error message "cannot 
deduce function from argument types !()(TestType!int)" it does 
successfully resolve alias to a type.


You're starting in the wrong end - the type cannot yet be 
considered, since the compiler doesn't know the correct arguments 
to TestAlias. Given this code:


struct S(T...) {}
alias SS(T...) = S!(T, int);

void foo(T)(SS!T arg) {}

unittest {
foo(SS!string());
}

The error message is "template foo cannot deduce function from 
argument types !()(S!(string, int)), candidates are: foo(T)(SS!T 
arg)".


What the compiler needs to do is figure out what T needs to be in 
order for SS to return the type S!(int, int). SS hasn't resolved 
to a type yet at that point, because the compiler has no idea 
which arguments to give it.


These are the steps the compiler does when it evaluates a 
function call (simplified):


1) Figure out the overload set.
2) Weed out non-matching overloads.
3) Check that exactly one overload matches*.
4) Use that overload.

In step 2, the compiler looks at the types when the overload is a 
regular function. When it's a function template, it doesn't know 
the types yet, and IFTI tries to figure it out by a sort of 
pattern matching. In the case above, it doesn't find a 
S!(/*something*/) anywhere, and gives up.


If the compiler were to do something other than give up, we would 
need some algorithm to define what it should try, and in which 
order. As human beings, with impressive collections of 
pattern-matching circuits, we can easily see that it should try 
putting the first template argument into T. Getting to that 
conclusion is a lot harder for the poor, stupid compiler.


--
  Simen


*In the case where multiple overloads are a match, the best fit 
is chosen. If there's more than one best fit, or there's no 
match, you get a compile error.

[Issue 13903] std.array.removeIf for associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13903

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
Not sure whether such one/two-liners would be accepted to Phobos.

---
import std.experimental.all;

auto removeIf(alias pred, AA)(AA aa)
{
aa.byPair.filter!(not!pred).each!(e => aa.remove(e.key));
return aa;
}

void main()
{
auto aa = ["a" : 1, "b" : 2];
aa.removeIf!(a => a.key == "a").writeln;
}
---

But efficiency and bug-proneness are two good points.

--

Re: #dbugfix Issue 16486 200$

[Simen Kjærås via Digitalmars-d]

On Friday, 30 March 2018 at 15:49:30 UTC, jmh530 wrote:

On Friday, 30 March 2018 at 15:21:26 UTC, jmh530 wrote:

[snip]



Doesn't extend to multiple template parameters that well...

import std.traits : TemplateOf;

struct TestType(T, U) {}
alias TestAlias(T) = TestType!(T, int);

template testFunction(T, alias U = TemplateOf!(TestAlias!T))


What you're showing here is a somewhat different case. First, 
you're telling TestAlias to turn into a TestType. Then you ask 
which template that type is an instance of. That's going to be 
TestType, every single time. And it being anything else would be 
a source of great confusion:


auto a = TestType!(string, int)();
auto b = TestAlias!string();

// We expect this to be true:
assert(is(typeof(a) == typeof(b)));

// And I'll be damned if this ain't:
assert(__traits(isSame, TemplateOf!(typeof(a)), 
TemplateOf!(typeof(b;


--
  Simen

Re: Reactive data

[lempiji via Digitalmars-d-learn]

On Friday, 23 March 2018 at 12:59:23 UTC, crimaniak wrote:

I want to have reactive variables like in this example:

```
USING_REACTIVE_DOMAIN(D)

// The two words
VarSignalT firstWord  = MakeVar(string( "Change" ));
VarSignalT secondWord = MakeVar(string( "me!" ));
// ...
SignalT bothWords = firstWord + string( " " ) + 
secondWord;

```

from this page: 
http://schlangster.github.io/cpp.react/tutorials/BasicSignals.html


Is this possible to make it in D with 
https://github.com/lempiji/rx ? Is there other libraries exists 
for this topic?


I think that it can use combineLatest which was recently added.
If using 'alias this' or 'operator overloading', might look like 
more original example.


---
import rx;

auto firstWord = new BehaviorSubject!string("Change");
auto secondWord = new BehaviorSubject!string("me!");

auto bothWords = new BehaviorSubject!string("");
combineLatest!((a, b) => a ~ " " ~ b)(firstWord, 
secondWord).doSubscribe(bothWords);


writeln(bothWords.value); // Change me!

firstWord.value = "TEST";
writeln(bothWords.value); // TEST me!
---

[Issue 13880] nothrow @nogc std.algorithm.reduce on fixed-size arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13880

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
https://github.com/dlang/phobos/pull/6398

--

[Issue 18700] New: iota with floating type + padRigh asserts

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18700

  Issue ID: 18700
   Summary: iota with floating type + padRigh asserts
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: santerkr...@gmail.com

The following triggers an assertion std.range.package.d (source line 5632 for
tag 2.079.0):

iota(6.).padRight(0, 10).slide(4)

The problem occurs when:
 - iota is floating type
 - padRight causes padding to the original size of the iota plus the size of
the slide (e.g. 6 + 4 == 10 in the above)

--

[Issue 13865] std.range.rangeSplit

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13865

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
This has been added a long time ago:

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

--

[Issue 13825] relativePath not handling "." and ".." correctly

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13825

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 5849] std.random.dice is better as a range

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5849

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #11 from Seb  ---
FYI: Here's my implementation of the alias method for mir:

https://github.com/libmir/mir/blob/da76cf406d06957e472b9ba90b4c90b917480cb9/source/mir/random/discrete.d

(it's Boost-licensed)

--

[Issue 11597] Speed up std.random.dice

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11597

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
> See Vose's Alias Method:

Here's my implementation for mir:

https://github.com/libmir/mir/blob/da76cf406d06957e472b9ba90b4c90b917480cb9/source/mir/random/discrete.d

tl;dr:
- std.random's methods should be available as Generators / "Variables"
- Until std.random isn't rewritten it probably doesn't make sense to patch it
partially

There's also:

https://issues.dlang.org/show_bug.cgi?id=5849

--

Re: D mentioned in Infoworld

[ElectronCharge via Digitalmars-d]

On Thursday, 29 March 2018 at 13:39:25 UTC, Steven Schveighoffer 
wrote:

On 3/26/18 11:52 AM, Jean-Louis Leroy wrote:
as a "programming languages you should learn now" - albeit 
somewhat dismissively ;-)


https://www.infoworld.com/article/3263395/application-development/the-programming-languages-you-should-learn-now.html



"If you’re programming in C or C++, you’re doing embedded 
stuff, drivers, or low-level stuff—or you’re just old"


Ouch! Also, destroys any credibility of the author. Moving on...


Yes, this was an inane article... It also included the horrible 
advice:


"Languages you should not learn today
[...]

Java
If you’re not a seasoned Java developer or planning to work for a 
body shop like Wipro or Infosys, by the time you don’t suck in 
Java your friends will have run rings around you careerwise in 
JavaScript as “full-stack developers.”"


Er, a whole lot of backend code is not written in Javascript, and 
for good reason. Java is near the top of of the heap as far as 
hiring goes, and Java developers generally command a better 
salary than front-end developers. Java is also pretty good to 
work with today, Java 8 added a lot of nice functional features.


It's insane that Swift wasn't mentioned anywhere in the article. 
It also left out some interesting, influential languages like 
Haskell, Julia, Nim, Dart, Typescript and Clojure. I hope not too 
many folks are basing decisions on that tripe.

[Issue 13797] std.array.extend

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13797

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
Hmm. Why can't we handle this on a language level?

---
int[] arr;
arr ~= [0, 1, 2];
---

works fine. So I don't see any reason why the compiler couldn't be improved to
accept this too:

---
int[] arr;
arr ~= 3.iota;
---

Custom data types can already do this with operator overloading, but built-in
arrays can't.

I submitted an enhancement request:
https://issues.dlang.org/show_bug.cgi?id=18699

--

[Issue 18699] New: D's builtin arrays could allow a more generic opBinaryAssign with range support

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18699

  Issue ID: 18699
   Summary: D's builtin arrays could allow a more generic
opBinaryAssign with range support
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

(from https://issues.dlang.org/show_bug.cgi?id=13797 where it was proposed to
add a new Phobos function for this)

tl;dr: appending an array to an array works fine today:

---
int[] arr;
arr ~= [0, 1, 2];
---

So I don't see any reason why the compiler couldn't be improved to accept this
too:

---
int[] arr;
arr ~= 3.iota;
---

Custom data types can already do this with operator overloading, but this is
not possible for built-in arrays.
The lowering should be trivial as D already allows ranges for `foreach`:

---
int[] arr;
foreach (e; 3.iota)
arr ~= e;
---

--

[Issue 13724] std.datetime.timeIt

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13724

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

Re: D mentioned in Infoworld

[bauss via Digitalmars-d]

On Saturday, 31 March 2018 at 13:53:30 UTC, Bienlein wrote:
This is interesting. Maybe I write a little framwork or 
something in Kotlin and file it on github. Then I have 
something to show in any case. And from then on I can just play 
with D ;-)


Yep, that's pretty much what I did. I had some projects on Github 
along with some .NET code and they were more interested in my D 
code than my .NET code.

[Issue 13507] std.range.enumerate with BigInt indexes too

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13507

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 13482] std.algorithm.podSort

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13482

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #2 from Seb  ---
> A pair of overloaded functions like this could be useful to add to Phobos to 
> avoid most of the template bloat caused by std.algorithm.sort in the 
> situations where the maximum sorting performance and flexibility (this just 
> accepts an array) is not strictly necessary:

(OP proposes a solution with if constraint "bloat")

I think if there are any issues with std.algorithm.sort / its templates, we
should try to address these instead of promoting such "workarounds" in the
standard library.
Closing as WONTFIX.

Please feel free to open issues regarding sort or problems with templates.

--

[Issue 13473] std.algorithm.expand

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13473

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #3 from Seb  ---
> Aren't all cases of "expand" reducible to "recurrence"? Do you have an 
> example where this isn't possible / is too ugly?

The closest pedant that D has to unfoldr (apart from recurrence) is its
Generator:

---
import std.experimental.all;
void main()
{
new Generator!int({
foreach (i; 0 .. 10)
yield(i);
}).writeln;
}
---

https://run.dlang.io/is/DQgDN3

So I'm not sure if there's anything actionable to be taken from this issue?

--

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18649

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #7 from Martin Nowak  ---
- The libcurl dependency should be demoted to recommended (installed by
default) or suggested, atm. it's still a dependency.

- It's confusing to see libcurl3 as dependency and libcurl4-openssl-dev as
suggestion.
 
https://github.com/dlang/installer/blob/47830a15d1a576b683c92b4bb4adc4a1d83a2b5d/linux/dmd_deb.sh#L347-L348
  Has anyone ever succeeded to install that with `-o
APT::Install-Suggests="true"` or `--install-suggests`?

- It's a pity that debian doesn't have a meta-package for libcurl, but I'd
research how other packages resolved this issue (libcurl-ocaml depends on
libcurl3-gnutls while libcurl-ocaml-dev depends on libcurl4-gnutls-dev).

- Use an alternative package name `libcurl4 | libcurl3` to support
installations without libcurl4 availability. Assuming that all OSes with
libcurl4 switch to that by default, otherwise you'd be back to the conflict.

So how about:
DEPENDS='libc6, libc6-dev, gcc, libgcc1, libstdc++6'
RECOMMENDS='libcurl4 | libcurl3'
SUGGESTS='libcurl4-openssl-dev, gcc-multilib'

--

[Issue 13104] std.typecons.tupleOp

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13104

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---

Have a look at https://github.com/dlang/phobos/pull/6386

with this the following will work:



(tuple(1, 2) ~ tuple(3, 4)).expand.only.sum = 10
(tuple(1, 2) ~ tuple(3, 4)).expand.only.max = 4


> tupleOp2!q{a + b}(tuple(1, 1.5), tuple(2, 3.2))

So here's what we got today:

zip(tuple(1, 1.5).expand.only, tuple(2, 3.2).expand.only).map!(a => a[0] +
a[1]).writeln;

https://run.dlang.io/is/6rq9MB

What I think could be improved:

- make tuples ranges by default (no .expand.only hacks)
- allow map to take a multi-argument lambda if the size of the front's element
is statically known

--

Re: D mentioned in Infoworld

[Bienlein via Digitalmars-d]

On Thursday, 29 March 2018 at 16:10:55 UTC, Johannes Loher wrote:

I have to say, my experience was totally different. I recently 
had quite many job interviews for jobs in which I would mainly 
be using Java/C#. Because I like D very much, obviously the 
topic came up in every single interview. Most of the time, I 
was encouraged to solve the simple programming tasks they gave 
me in D. I think they were actually quite impressed, both by D 
itself and the fact that I am interested in such a "niche" 
language. I believe showing that you are enthusiatic about such 
things can help you with getting jobs much more than some 
experience in a language which is "closer" to the language they 
mainly use.


Yes, I beliebe that enthusiasm and passion is something people 
are sometimes looking for at job interviews. In my last job 
interview I showed some passion about concurrent programming and 
I think they like that, that is the passion. Whether it is about 
concurrent programming or D might not be that important.


I landed a previous job using .NET about two years ago, because 
of some D code I >had written, so for me the experience is 
different too.


This is interesting. Maybe I write a little framwork or something 
in Kotlin and file it on github. Then I have something to show in 
any case. And from then on I can just play with D ;-)

[Issue 12592] std.algorithm.keep to filter range elements and write back to the source range

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12592

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--

[Issue 12844] Absurd RAM Required for ctRegex

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12844

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #10 from Seb  ---
>From https://github.com/dlang/phobos/pull/6164#issuecomment-365175755:

> Another idea is to deprecate ctRegex and stop testing it. It's 100% obvious 
> that it doesn't work on anything significant in practice due to our compiler 
> limitations. Then we enable it again once CTFE works with std.regex.

--

Re: rvalues -> ref (yup... again!)

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/18 9:28 AM, Timon Gehr wrote:

On 30.03.2018 11:06, Atila Neves wrote:


Right, and I was assuming (perhaps incorrectly) that this existing 
code was C++, hence me being on board with binding rvalues to const 
ref there.


That must not happen. D const and C++ const don't even mean the same 
thing, and now suddenly you will see people use extern(C++) just to get 
the binding of rvalues to ref. Add to this the confusing overload 
behavior if const signifies anything other than read-only.


This is a very important aspect that must not be overlooked.

Allow me to reiterate: the one way to get this going is convert the 
forum dialog into a team and a DIP.



Andrei

Re: #dbugfix Issue 16486 200$

[Kagamin via Digitalmars-d]

On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:
Ah that is an interesting bug which further demonstrates that 
templates are a tricky thing :)
Basically you cannot _generally_ proof that one template just 
forwards to another.

Therefore you have to create separate types.
And since you create separate types the alias is not an alias 
but a separate template.
Solving this may be possible for special cases but in the 
general case is infeasible.


If a template is used as a type it should be resolved to a type, 
no? And template resolves to a type in a straightforward way. 
Where does it fail? Judging by the error message "cannot deduce 
function from argument types !()(TestType!int)" it does 
successfully resolve alias to a type.

Re: rvalues -> ref (yup... again!)

[Timon Gehr via Digitalmars-d]

On 30.03.2018 11:06, Atila Neves wrote:


Right, and I was assuming (perhaps incorrectly) that this existing code 
was C++, hence me being on board with binding rvalues to const ref there.


That must not happen. D const and C++ const don't even mean the same 
thing, and now suddenly you will see people use extern(C++) just to get 
the binding of rvalues to ref. Add to this the confusing overload 
behavior if const signifies anything other than read-only.

[Issue 18698] static foreach + __traits(allMembers, moduleName)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18698

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #2 from Ketmar Dark  ---
lol. another `static foreach` great feature: `allMembers` tries to expand
`static foreach`, effectively executing it's body, whith calls `allMembers`,
which tries to expand `static foreach`, effectively...

--