Re: D on quora ...

[Adam Wilson via Digitalmars-d]

On 10/6/17 14:12, Rion wrote:

[snip]


When every new languages besides Rust or Zig are GC. That same "flaw" is
not looked upon as a issue. It seems that D simply carries this GC
stigma because the people mentioning are  C++ developers, the same
people D targets as a potential user base.

D can have more success in targeting people from scripting languages
like PHP, Ruby, Python, where the GC is not looked upon as a negative.
The same effect can be seen in Go its popularity with drawing developers
from scripting languages despite it not being there intention.

I always felt that D position itself as a higher language and in turn
scares people away while at the same time the people it wants to
attracts, with most are already set in there ways and looking at excuses
to discredit D. The whole C++ has all of D features and does not need a
GC / GC is bad excuse we see in the quora.com posting fits that
description ( and not only there, also on other sites ).


What if we stop focusing on the C/C++ people so much? The like their 
tools and have no perceivable interest in moving away from them 
(Stockholm Syndrome much?). The arguments the use are primarily meant as 
defensive ploys, because they compare everything to C/C++ and when it 
doesn't match in some way or another the other language must be 
deficient. They've already decided that C/C++ is the meter stick against 
which all other languages are to be judged. Unsurprisingly, nothing that 
is NOT C/C++ meets their exacting demands.


I saw we ditch the lot and focus on the large languages where D can get 
some traction (C#/Java).


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: Having trouble porting basic GLFW C++ example to D

[Matt Jones via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 04:24:07 UTC, Matt Jones wrote:

On Saturday, 7 October 2017 at 03:47:27 UTC, Joakim wrote:

On Saturday, 7 October 2017 at 03:12:09 UTC, Matt Jones wrote:

[...]


Heh, that's the problem.


[...]


I ran into this myself, took me awhile to track it down.  I 
too took the size of dynamic arrays this way:


[...]


Ah. I should have remembered that problem. Thanks. I'll see if 
that fixes it.


Nice! That worked. Thanks.

Re: D on quora ...

[Jon Degenhardt via Digitalmars-d]

On Saturday, 7 October 2017 at 03:15:41 UTC, Laeeth Isharc wrote:
On Saturday, 7 October 2017 at 01:00:41 UTC, Jon Degenhardt 
wrote:
Have there been studies quantifying the performance of D's GC 
relative to other GC implementations? My anecdotal experience 
is that D's GC can have undesirable latency behavior (long 
pauses), but throughput appears good. Of course, quantified 
metrics would be far preferable to anecdotal observations.


--Jon


Have you tried running the GC instrumentation on your tsv 
utilities? That might make for a very interesting blog post.


Well, I have for the tsv utilities and some other programs. 
That's what's behind my observations. While interesting, I don't 
think I have enough definitive data to draw conclusions for a 
blog post. Two specifics:
(1) GC profile data shows long max pause times in several 
benchmarks. However, where it has occurs it's clearly associated 
with very large AAs. It may not be representative of more common 
use cases. (There is more quantification I could do here though.)
(2) The benchmarks I've run are all on throughput oriented tasks. 
In these the D programs have compared well to other native 
compiled programs, mostly using manual memory management. I think 
this does say something to the effect that choosing good 
algorithms and memory use approaches is usually more important 
than the GC vs manual memory selection. And, it is consistent 
with a good throughput story for D's GC, but is hardly a direct 
comparison.

Re: Having trouble porting basic GLFW C++ example to D

[Matt Jones via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 03:47:27 UTC, Joakim wrote:

On Saturday, 7 October 2017 at 03:12:09 UTC, Matt Jones wrote:

[...]


Heh, that's the problem.


[...]


I ran into this myself, took me awhile to track it down.  I too 
took the size of dynamic arrays this way:


[...]


Ah. I should have remembered that problem. Thanks. I'll see if 
that fixes it.

Re: Having trouble porting basic GLFW C++ example to D

[Joakim via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 03:12:09 UTC, Matt Jones wrote:
I've been trying to port a basic GLFW C++ example to D. The C++ 
version shows the textures correctly. But the D version shows 
nothing. The code is almost identical.


Heh, that's the problem.


Does anyone know why the D version does not work?

https://github.com/workhorsy/d_glfw


I ran into this myself, took me awhile to track it down.  I too 
took the size of dynamic arrays this way:


https://github.com/workhorsy/d_glfw/blob/master/dlang/source/main.d#L158
https://github.com/workhorsy/d_glfw/blob/master/dlang/source/main.d#L161

That will give you 2 words for a slice or dynamic array, the 
length and pointer.  What you want is the length of the array


https://github.com/joakim-noah/android/blob/master/samples/Teapot/jni/TeapotRenderer.d#L192

multiplied by the size of the element

https://github.com/joakim-noah/android/blob/master/samples/Teapot/jni/TeapotRenderer.d#L195

Sizeof works for static arrays, but is different for slices: 
that's likely your problem.

Re: D on quora ...

[Laeeth Isharc via Digitalmars-d]

On Saturday, 7 October 2017 at 01:00:41 UTC, Jon Degenhardt wrote:

On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
On Fri, Oct 06, 2017 at 06:09:58PM +, Ali via 
Digitalmars-d wrote:
The reputation is D's GC is slow, and Manual Memory 
Management is fast


The first point is valid (when are we going to get a better 
GC? :-/), but the second is questionable.


Have there been studies quantifying the performance of D's GC 
relative to other GC implementations? My anecdotal experience 
is that D's GC can have undesirable latency behavior (long 
pauses), but throughput appears good. Of course, quantified 
metrics would be far preferable to anecdotal observations.


--Jon


Have you tried running the GC instrumentation on your tsv 
utilities? That might make for a very interesting blog post.

Having trouble porting basic GLFW C++ example to D

[Matt Jones via Digitalmars-d-learn]

I've been trying to port a basic GLFW C++ example to D. The C++ 
version shows the textures correctly. But the D version shows 
nothing. The code is almost identical. Does anyone know why the D 
version does not work?


https://github.com/workhorsy/d_glfw

Re: Eilmer4 - a Computational Fluid Dynamics code in D

[Joakim via Digitalmars-d-announce]

On Friday, 6 October 2017 at 23:49:33 UTC, Bastiaan Veelo wrote:

On Friday, 6 October 2017 at 22:16:09 UTC, Peter Jacobs wrote:
Eilmer is a simulation code for studying high-speed 
compressible flows.  Early versions were written in C and then 
C++.  Version 4 is a complete rewrite in D, with Lua for 
configuration and run-time scripting.  Code and documentation 
may be found at http://cfcfd.mechmining.uq.edu.au/eilmer/


This note is principally to say thank you to all of the people 
who have made the D programming language and its ecosystem.  
Being mechanical engineers, we are occasional but serious 
programmers.  For a number of years, we struggled with C++ and 
a code base of growing complexity.  In 2014, we made a serious 
commitment to reworking the entire code into D. In mid-2017, 
the new code was complete enough for general use and it is 
currently being used in a fourth-year course on computational 
fluid dynamics.  The D programming language has enhanced our 
programming experience and, for that, we are grateful to the 
many people who have built the foundation upon which we build 
our flow simulation code.


Cheers,
Peter Jacobs and Rowan Gollan


Congtatulations on a job well done. Your motivation for use of 
the D Programming Language is the same as ours. I found your 
paper describing the rewrite [1] very interesting, I think it 
deserves a more prominent mention here and on the usual news 
sites.


Bastiaan

[1] 
http://cfcfd.mechmining.uq.edu.au/eilmer/pdfs/T0316-eilmer-dlang-v2.pdf


I like how you have setup instructions and docs on your site.

Two relevant quotes from the paper:

"With the recent maturing of the programming language D as a good 
alternative to C++ for statically-checked, natively-compiled 
code, we have taken the opportunity to rebuild our simulation 
code. The D programming language provides the conveniences of 
Python, the run-time performance of C++ and the ability to be 
directly linked to C language libraries. It appears that we can 
have it all and we can have it now. One good example of where the 
rebuild has resulted in significant improvements is the 
viscous-flux calculation code. In the C++ code, about 2500 lines 
were used, and this had the extra complication of requiring the 
M4 preprocessor to produce the actual C++ code (of length 5580 
lines) that was given to the compiler. The new D language code 
amounts to 733 lines."


"Conclusion
We have spent much of a year building a new compressible flow 
simulation code from scratch, in a relatively new language. So 
far, our experience with the D programming language has been 
positive, with a fairly capable simulation code being constructed 
with a few months of effort by two people. Together with some 
code redesign, the D programming language has allowed the 
construction of a code base that is much simpler than its C++ 
predecessor but is just as fast."


Mike, want to stick this on proggit and HN?

Re: gdc is in

[Joakim via Digitalmars-d]

On Friday, 6 October 2017 at 20:34:20 UTC, John Colvin wrote:

On Friday, 6 October 2017 at 17:04:39 UTC, Iain Buclaw wrote:
On 6 October 2017 at 17:21, jmh530 via Digitalmars-d 
 wrote:

On Friday, 6 October 2017 at 15:04:25 UTC, Joakim wrote:



I assume you mean ddmd and static foreach, the mailing list 
post linked from my link implies it includes both.



I would think this would be bigger news...I mean LDC isn't 
even on 2.076 yet...



Really?  Well, maintenance should be rather small now that the 
patch / diff is relatively tiny for GDC.  Rebasing only 
against dmd/stable branch on a weekly basis or so should help 
things along also.


A lot of (most, even?) D users ignore GDC because it's been 
substantially behind the cutting edge for so long. Managing to 
catch up and become relevant to them is big news, if you want 
users.


To clarify: this includes Phobos, right?


Yes, the gdc downloads page hasn't been updated in 9 months:

https://gdcproject.org/downloads

By comparison, ldc is at the ddmd 2.074 frontend, which has been 
downloaded 7000 times in the last month since it was released:


http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

The gdc devs should put out a new release with a more up-to-date 
frontend and announce it, so that all this work they've done gets 
more use.

Re: D on quora ...

[Ilya Yaroshenko via Digitalmars-d]

On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:

https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non 
gc version in the future...


WIP:

https://github.com/libmir/mir-algorithm
https://github.com/libmir/mir-random
https://github.com/libmir/mir-cpuid

Re: D on quora ...

[Jon Degenhardt via Digitalmars-d]

On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
On Fri, Oct 06, 2017 at 06:09:58PM +, Ali via Digitalmars-d 
wrote:
The reputation is D's GC is slow, and Manual Memory Management 
is fast


The first point is valid (when are we going to get a better GC? 
:-/), but the second is questionable.


Have there been studies quantifying the performance of D's GC 
relative to other GC implementations? My anecdotal experience is 
that D's GC can have undesirable latency behavior (long pauses), 
but throughput appears good. Of course, quantified metrics would 
be far preferable to anecdotal observations.


--Jon

Re: D on quora ...

[Mengu via Digitalmars-d]

On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:

https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non 
gc version in the future...


as a d user, i do not give a single flying fuck about manual 
memory management. i love gc. period. please let gc be my guest 
and clean up everything for me. i have other problems like d / 
dmd / phobos failing me on freebsd; vibe.d working amazing on 
linux and throwing some random shit on freebsd.


d is better than java, let alone c++. they both are crap. 
garbage. incredibly explicit and verbose. yet they get work done 
for other people. and these people, since the inception of d are 
throwing random arguments against d. they never ran out of 
arguments. it was two std libs, it was two d versions, it was 
lack of 3rd party libs, it was lack of giant corp support, it was 
lack of community / resources, it was and it will be something 
for those people. until they decide to shut the fuck up and 
actually give d a try. just like great people we get here 
everyday.


a big problem of d is that it is a play-dough for many people 
here. they don't run into problems with d because they are mostly 
not eating their own dog food or incredible experts at d. 
(remember qtd guys?) if we have 100 wtf moments per hour, they 
probably have like 1-2 per year. they do more abstract stuff 
rather than concrete stuff. (atila & co, manu, sociomantic 
people, jacob and some more are exceptions). they are blind to 
newcomer problems. they also have prejudices like assuming you 
know all the low level stuff beforehand.


when your beloved language (or its toolchain) screws things up 
for the app you wrote and deployed and will be used by millions 
of people per year, you have more problems than you imagined 
earlier and gc is not one of them.

Re: Eilmer4 - a Computational Fluid Dynamics code in D

[Bastiaan Veelo via Digitalmars-d-announce]

On Friday, 6 October 2017 at 22:16:09 UTC, Peter Jacobs wrote:
Eilmer is a simulation code for studying high-speed 
compressible flows.  Early versions were written in C and then 
C++.  Version 4 is a complete rewrite in D, with Lua for 
configuration and run-time scripting.  Code and documentation 
may be found at http://cfcfd.mechmining.uq.edu.au/eilmer/


This note is principally to say thank you to all of the people 
who have made the D programming language and its ecosystem.  
Being mechanical engineers, we are occasional but serious 
programmers.  For a number of years, we struggled with C++ and 
a code base of growing complexity.  In 2014, we made a serious 
commitment to reworking the entire code into D. In mid-2017, 
the new code was complete enough for general use and it is 
currently being used in a fourth-year course on computational 
fluid dynamics.  The D programming language has enhanced our 
programming experience and, for that, we are grateful to the 
many people who have built the foundation upon which we build 
our flow simulation code.


Cheers,
Peter Jacobs and Rowan Gollan


Congtatulations on a job well done. Your motivation for use of 
the D Programming Language is the same as ours. I found your 
paper describing the rewrite [1] very interesting, I think it 
deserves a more prominent mention here and on the usual news 
sites.


Bastiaan

[1] 
http://cfcfd.mechmining.uq.edu.au/eilmer/pdfs/T0316-eilmer-dlang-v2.pdf

Re: Infuriating DUB/DMD build bug.

[Laeeth Isharc via Digitalmars-d-learn]

On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:


I've got a github project and using DUB with DMD and I keep 
running into this problem. I've tried deleting the entire 
...\AppData\Roaming\dub\packages folder, but the

problem repeats the very next build attempt.

[...]


See my post in learn on dmd path.  The dmd path code was written 
in 1987 and could do with an update to process longer windows 
paths properly.  We are working on this and I guess a chance a 
pull request on Monday but it depends on what else comes up.  In 
any case it's a trivial fix.


Presuming I am right about it being a path length problem.

Re: D on quora ...

[Moritz Maxeiner via Digitalmars-d]

On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:


I can make a few simple demos and have D use by default 5 to 10 
more memory then the exact same C or C++ program. While D does 
not actually use it ( its only marked as allocated for the GC 
), it does not dispel the notion or feeling of people that a GC 
= bad.


You can configure the GC to deal with that [1].



Other aspects like being unsure when the GC will trigger can 
also influence people to a non-gc language.


In general: The GC can only trigger when you request memory from 
it.
W.r.t to the current GC implementation, it will trigger when it 
doesn't have enough memory to fulfill an allocation request.
In short: You're always in control of exactly when GC pauses can 
occur. I recommend the GC series for further information [1].


[1] https://dlang.org/spec/garbage.html#gc_config
[2] https://dlang.org/blog/the-gc-series/

Re: D on quora ...

[Jonathan M Davis via Digitalmars-d]

On Friday, October 06, 2017 21:39:21 Ali via Digitalmars-d wrote:
> On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> > D's GC isn't going anywhere.
>
> Well, if I got the message correctly, it seems the key Dlang
> maintainers, are more sold on adding full support to
> Deterministic (manual) Memory management
>
> And a lot less sold on improving the existing GC
>
> So as I understand the current road map involve more work on
> Deterministic (manual) Memory management and a lot less work on
> improving the GC

There is definitely work being done towards improving more deterministic
forms of memory management, but there's also been work done towards
improving the GC. It just isn't talked about much.

And even some of the more deterministic memory management is still
potentially going to be using the GC (e.g. they've talked about introducing
better language support for reference counting but using the GC to take care
of cycles).

> And the requirement for the GC will be removed from the standard
> library

Some parts of the standard library will always require the GC. Much of it
does not. The idea is to avoid requiring the GC when it doesn't make sense
to require the GC, and there are cases where the GC is accidentally
required. For instance, on the whole, stuff like std.algorithm should not
use the GC and does not use the GC, but sometimes, when lambdas get
involved, closures end up being allocated, which means that the GC gets
used, and that may not have been intended or expected. Some of that can be
prevented, and some of it can't. Someone who wants to fully avoid the GC
probably will need to minimize passing lambdas to functions and prefer
functions or functors.

The main thing is that we need to ensure that the GC is not required when
it's not meant to be required. It has never been the plan to remove it from
Phobos completely. That really wouldn't make any sense, and in quite a few
cases, it literally can't be done (e.g. a number of functions were designed
to return newly allocated arrays; we can provide alternatives to them in a
number of cases, but we couldn't make the existing stuff not use the GC).

So, plenty of work still needs to be done to ensure that some stuff is
marked @nogc when it should be and ensure that the GC is not accidentally
used, but we're not stripping out the GC.

In some cases, it probably is just figuring out a way to make the
documentation clearer like Laeeth mentioned, but that can be a bit
entertaining given that whether something allocates is frequently a question
of what arguments it's given (e.g. very little in std.algorithm will ever
allocate if it's given a functor, but lots of it will allocate if it's given
a lambda or non-static nested function that the compiler decides might need
a closure allocated), and that can't really be covered by @nogc in the
documentation. You can use @nogc when you call it to ensure that you're not
triggering the GC, but it depends on what you passed, so it has to be
inferred rather than being explicitly documented as @nogc. And thus far, we
really haven't done anything to figure out how to document when whether
something uses the GC depends on what you pass it.

Regardless, I can absolutely guarantee that Walter and Andrei are not
planning to rip the GC out of everything. They just don't want to be
requiring it when we don't need to, and that's not something that Phobos has
always done a good job of, though a lot of the idioms it uses seriously
reduce GC usage.

- Jonathan M Davis

Eilmer4 - a Computational Fluid Dynamics code in D

[Peter Jacobs via Digitalmars-d-announce]

Eilmer is a simulation code for studying high-speed compressible 
flows.  Early versions were written in C and then C++.  Version 4 
is a complete rewrite in D, with Lua for configuration and 
run-time scripting.  Code and documentation may be found at 
http://cfcfd.mechmining.uq.edu.au/eilmer/


This note is principally to say thank you to all of the people 
who have made the D programming language and its ecosystem.  
Being mechanical engineers, we are occasional but serious 
programmers.  For a number of years, we struggled with C++ and a 
code base of growing complexity.  In 2014, we made a serious 
commitment to reworking the entire code into D. In mid-2017, the 
new code was complete enough for general use and it is currently 
being used in a fourth-year course on computational fluid 
dynamics.  The D programming language has enhanced our 
programming experience and, for that, we are grateful to the many 
people who have built the foundation upon which we build our flow 
simulation code.


Cheers,
Peter Jacobs and Rowan Gollan

Re: Need importing dcompute.lib into my project

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 6 October 2017 at 18:12:43 UTC, kerdemdemir wrote:

Hi,

I have a cuda kernel already working in my cpp 
project(https://github.com/kerdemdemir/CUDABeamformer/blob/master/CudaBeamformer/kernel.cu)


I am trying to convert this to D with using DCompute. I already 
compiled the DCompute source code and have dcompute.lib. But I 
am really not good with using libraries and don't know how to 
use DCompute in my D 
project(https://github.com/kerdemdemir/DSharpEar/tree/master/DSharpEar). I am not using DUB and compiling with VisualD.


Can you guys please help with importing DCompute into my 
project?


Regards
Erdem


You should add DCompute as a DUB dependancy.

Re: template auto deduction

[Alex via Digitalmars-d-learn]

On Friday, 6 October 2017 at 21:42:40 UTC, Steven Schveighoffer 
wrote:


What you need is IFTI or "Implicit Function Template 
Instantiation"


Note the "Function" part of it, in that it's only valid for 
functions.


So you need a factory function:

auto m(T)(T x)
{
  return M!(T)(x);
}

...

auto b = m(fs); // ok

There is an enhancement request to make constructors have the 
same mechanism. Not sure if or when it would be implemented.


-Steve


Ha! Yes :)
Thanks a lot :)
That's what is meant by convenience methods inside the library, 
sometimes...

Re: template auto deduction

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/6/17 5:08 PM, Alex wrote:

Hey, template gurus :)

given this:

struct M(alias I : S!E, alias S, E...)
{
 R!E r;
 this(S)(S initStruct)    // line 4
 {
     r = R!E(initStruct);
 }
}
struct R(E...)
{
 this(S)(S initStruct)    // line 12
 {
     // do some cool stuff
 }
}
void main()
{
 FS!(Etype1) fs;
 auto m = M!(typeof(fs))(fs);    // line 21.
 auto a = M!(fs); // does not work
 auto b = M(fs); // does not work
}
struct FS(T...){}
struct Etype1{}

Everything works as expected, especially line 21. The question is about 
syntactic sugar: What I have to change, to use auto deduction and to 
create the M struct like in line 22 or 23?


By the way, I'm aware, that the type matching in lines 4 and 12 is lost, 
in the way it is written here. However, it is meant to exist, if this 
helps in some way...


Thanks a lot in advance
Alex


What you need is IFTI or "Implicit Function Template Instantiation"

Note the "Function" part of it, in that it's only valid for functions.

So you need a factory function:

auto m(T)(T x)
{
  return M!(T)(x);
}

...

auto b = m(fs); // ok

There is an enhancement request to make constructors have the same 
mechanism. Not sure if or when it would be implemented.


-Steve

Re: Iterating over functions in module in order?

[Alex via Digitalmars-d-learn]

On Thursday, 5 October 2017 at 00:24:12 UTC, Jerry wrote:
Any ideas on how someone could iterate over functions in a 
module as they appear, rather than any random order, without 
having to manually label them?


Do you mean something like this?

/// --- code ---
module test165;

import std.stdio;
import std.traits : isFunction;

void main()
{
immutable b = [ __traits(allMembers, mixin(__MODULE__)) ];

static foreach(i, _; b)
		static if(isFunction!(__traits(getMember, mixin(__MODULE__), 
b[i])))

writeln(b[i]);
}

auto fun1(){}
struct S;
int i;
double[] arr;
auto fun3(int val){}
auto fun2(T)(T notAfun) {}
/// --- code ---

I saw a similar problem here:
http://forum.dlang.org/post/xratcdpxfepxowghj...@forum.dlang.org

Re: D on quora ...

[Ali via Digitalmars-d]

On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:

D's GC isn't going anywhere.


Well, if I got the message correctly, it seems the key Dlang 
maintainers, are more sold on adding full support to 
Deterministic (manual) Memory management


And a lot less sold on improving the existing GC

So as I understand the current road map involve more work on  
Deterministic (manual) Memory management and a lot less work on 
improving the GC


And the requirement for the GC will be removed from the standard 
library

Re: Proposal: Object/?? Destruction

[Steven Schveighoffer via Digitalmars-d]

On 10/6/17 3:31 PM, Timon Gehr wrote:

On 06.10.2017 14:26, Steven Schveighoffer wrote:

On 10/5/17 3:42 PM, Timon Gehr wrote:

On 05.10.2017 17:40, Steven Schveighoffer wrote:

On 10/5/17 2:42 AM, Timon Gehr wrote:

The only unresolved question is (as using the result of the comma 
operator has been deprecated already): How to write a unary tuple. 
My favourite is what python does: "(3,)". This is however already 
accepted as a function argument list. I think it is worth breaking 
though. Maybe we should deprecate it.


I know you have an answer for this, but pardon my ignorance.


I indeed have strong opinions on how to do this correctly, as I have 
given some thought to it when designing the (still quite basic) type 
system of PSI: https://github.com/eth-srl/psi


The idea is to follow type theory/mathematics where the type of 
functions is a binary type constructor taking domain and codomain to 
the type of functions mapping values from the domain to values from 
the codomain. Multiple function arguments are just the function 
applied to a tuple of values.



Why isn't (a) good enough?



typeof((a)) should be typeof(a). This is just a parenthesized 
expression, as in (a+b)*c.


Right, I agree.


typeof((a,)) should be (typeof(a),).


I guess my question is more in the context of the problem at hand:

int foo();

auto (a) = foo();

why can't this work?
...


This could be made to compile, but this is not really about tuples.

But then of course, it shouldn't work, because int is not a tuple. So 
I suppose I have answered my own question -- we need a way to specify 
a tuple of one for prototype foo!


Indeed, my experience with tuples and their usage is quite limited.

Even though the syntax is straightforward and unambiguous, it looks 
incorrect, like you forgot something.

...


That's not necessarily bad. (When is the last time you have used a 
singleton tuple?)


I'm not an expert in language design, but would it be worth exploring 
other punctuation that isn't used in the language currently to allow 
better syntax? It seems like the trailing comma is to get around 
ambiguity,


It's the comma that indicates tupling, so there is not really ambiguity, 
the expression (a) just is not a tuple. To indicate a tuple you need to 
use the tupling operator ','. Trailing commas are allowed for all 
tuples, but for singleton tuples they are also necessary.


but there would be no ambiguity if you used something other than 
current punctuation to surround the tuple.


Angle brackets come to mind .


D avoids angle brackets.

Also you could use a leading symbol to change the meaning of the 
parentheses, like $(a).

...


This is very noisy, and once you go with non-standard tuple syntax, you 
can just as well use tuple(a).



---
(int,) foo(int a){ return (a,); } // turn value into singleton tuple
int bar(int a,){ return a[0]; }   // turn singleton tuple into value

void main(){
 foo(2,); // error: cannot convert (int,) to int
 bar(2); // error: cannot convert int to (int,)
 auto (x,) = foo(2); // ok, x has type int
 auto y = bar(2,); // ok y has type int
 auto z = foo(2); // ok, z has type (int,)
}
---

---
// The following two function signatures are equivalent (identical 
name mangling):

(int,string) foo(int a,string b){
 return (a,b);
}

(int,string) foo((int,string) x){
 return x;
}
---


So I will ask, what is the usage of foo here?

In the first example (foo and bar), you can't call a function that 
takes a tuple with a single value, and you can't call a function that 
takes a value with a single tuple (BTW, this is not how AliasSeq 
works, you can call functions that take a single arg with single 
element tuples).

...


AliasSeq auto-expands. If you call a function with a single element 
AliasSeq, it will expand to a single value and not be an AliasSeq 
anymore. Built-in tuples should not auto-expand, so a singleton tuple 
stays a singleton tuple (they will have an explicit .expand property).


In your second example, where foo takes a 2-element tuple or 2 values, 


All functions take a single value. That value might be a tuple. (Of 
course, we will continue to say that a function can take multiple 
arguments, because it is convenient, but what this _means_ is that it 
takes a single tuple argument.)


you say the name mangling is equivalent. Does that mean if I only 
define the tuple version, I can call it with foo(1, "hello") and vice 
versa? 


Yes. (Both options are "the tuple version".)


This seems to contradict your example above.
...


No. All functions take one argument and produce one result. (The 
argument and the result may or may not be a tuple, but there is no 
essential difference between the two cases.) You can match a value 
against a pattern on the function call.


It is weird to me that a function with 2 parameters is the same as a 
function that takes a 2-element tuple, but a function with one parameter 
is not the same as a function that takes a 

Re: Should we add `a * b` for vectors?

[Jonathan M Davis via Digitalmars-d]

On Friday, October 06, 2017 21:05:05 jmh530 via Digitalmars-d wrote:
> On Friday, 6 October 2017 at 20:36:47 UTC, Jonathan M Davis wrote:
> > It forces them to actually be designed with the type and be
> > easily located with the type. Would you want a programmer to be
> > able to go and implement opBinary!"+" for strings? I sure
> > wouldn't. And I don't want anyone doing that for user-defined
> > types that they didn't define either.
>
> Tangentially (I admit), there's nothing stopping you from below:
>
> struct MyString
> {
>  string mystring;
>  alias mystring this;
>  string opBinary(string op)(string rhs)
>  if(op == "+")
>  {
>  return mystring ~ rhs;
>  }
> }
>
> void main()
> {
>  MyString x = MyString("foo");
>  string y = "bar";
>  auto z = x + y;
>  assert(z == "foobar");
> }

Yes, but then at least it's a type that you've defined to be dumb like that
rather that built-in's or someone else's type being hijacked to behave
badly. It's not like we're going to stop every stupid thing that someone
could do (and if we did, it would severely limit our ability to do
intelligent things), but I see no value in allowing 3rd parties to tack on
overloaded operators onto types that they do not control.

- Jonathan M Davis

[Issue 17881] Provide mechanism to preallocate memory from the GC

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

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

--- Comment #4 from Steven Schveighoffer  ---
Stevens-MacBook-Pro:testd steves$ cat testpreallocate.d
struct S
{
S *next;
}

void main()
{
version(freelist)
{
S* head = null;
foreach(i; 0 .. 20_000_000)
head = new S(head);
}
version(preallocate)
{
S* head = null;
auto x = new S[20_000_000];
foreach(i; 0 .. 20_000_000)
{
x[i] = S(head);
head = &(x[i]);
}
}
}
Stevens-MacBook-Pro:testd steves$ dmd -O -release testpreallocate.d
-version=freelist
Stevens-MacBook-Pro:testd steves$ time ./testpreallocate

real0m1.869s
user0m1.750s
sys0m0.114s
Stevens-MacBook-Pro:testd steves$ dmd -O -release testpreallocate.d
-version=preallocate
Stevens-MacBook-Pro:testd steves$ time ./testpreallocate

real0m0.111s
user0m0.045s
sys0m0.062s


The point is that the GC is not well-equipped to handle the tight allocation
loop.

The second version has the drawback that all 20 million elements will remain in
memory as long as there is one element still alive.

What I'm looking for is something that has the performance (or similar, I
realize it won't be as good) of the second, but can collect each block
individually like the first.

--

Re: Should we add `a * b` for vectors?

[jmh530 via Digitalmars-d]

On Friday, 6 October 2017 at 20:36:47 UTC, Jonathan M Davis wrote:


It forces them to actually be designed with the type and be 
easily located with the type. Would you want a programmer to be 
able to go and implement opBinary!"+" for strings? I sure 
wouldn't. And I don't want anyone doing that for user-defined 
types that they didn't define either.




Hmm, you could think of it like the current default is that you 
cannot do outer operator overloading. We have @disable this(); 
for disabling default construction. What about something like

@outer T opBinary(string op)(T)
if(op == "+")
which means that it allows opBinary to be defined outside the 
struct/class. The default would be that it's not allowed. And it 
would give a hint to somebody that they would need to look for 
that method elsewhere?

Re: D on quora ...

[Rion via Digitalmars-d]

On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
D's GC isn't going anywhere. The implementation may be improved 
or replaced, but there are huge advantages to having the GC 
(particularly with regards to memory safety), and there _are_ 
actually times when using a GC is faster than something like 
reference counting.


We don't want D's standard library to rely on the GC when it 
doesn't need to, but there are language features that require 
it and really couldn't work with it, and there are cases where 
it's going to be involved by default for @safety reasons. For 
someone who wants to avoid the GC or minimize its use, there 
are things that they will need to do (e.g. you have to be 
careful with lambdas and probably use functors or functions, 
because closures are frequently needed when dealing with 
lambdas, and that means using the GC; @nogc will catch those 
cases for you so that you know when a lambda isn't going to 
work). But while it should be possible for someone to avoid the 
GC if they need to, that does not mean that we're looking to 
get rid of it or even have not using it be the default. It just 
means that we don't want to force its use where that doesn't 
make sense.


Honestly, I would _hate_ to use D without a GC. Without it, 
@safe memory managament would not be possible, and you'd have 
to valgrind everything. As it stands, you only have to do that 
when you have sections of @trusted code that would potentially 
be a problem. And there's a lot of code that's cleaner for not 
having to worry about managing memory.


That's not to say that using the GC is always better or that 
other solutions are not more appropriate for some circumstances 
- and the fact that D gives you control over a lot of that is 
fantastic - but this idea that GCs are always nothing but bad 
and should be avoided by the plague is just nonsense. GCs have 
their pros and cons, but they can be fantastic, and idiomatic D 
programs actually mitigate a lot of the downsides that you can 
get with a GC, because they do so much with the stack rather 
than the heap (which is generally better performance-wise 
regardless of how heap allocations are managed).


Yes, we could use a better GC, but overall, the GC is really 
just a PR problem and not a real one. Most programs can use it 
and be plenty performant. And those that can't have the tools 
necessary to minimize its use or even outright avoid it (though 
honestly, if someone is looking to outright avoid it, I'd lean 
towards wondering what the point of using D was in the first 
place; the proponents of the -betterc stuff still think that 
it's worth it though). Plenty of folks have managed to write 
performant programs that involve D's GC.


- Jonathan M Davis


The issue is only mentioned, because it keeps getting talked 
about ( mostly one sided ) on forums and sites like the above 
mentioned quora.com. Its hard to change people there perception, 
without counter arguing. Currently as i write this, these claims 
on quora are unchallenged.


I can make a few simple demos and have D use by default 5 to 10 
more memory then the exact same C or C++ program. While D does 
not actually use it ( its only marked as allocated for the GC ), 
it does not dispel the notion or feeling of people that a GC = 
bad.


Other aspects like being unsure when the GC will trigger can also 
influence people to a non-gc language. The Go developers have 
done a massive ( an impressive ) amount of work on trying to 
reduce GC pauses in the last two years, and that communication 
and effort has helped to reduce the GC myth ( for people looking 
at Go ).


Another part of the issue is, while D can be run without the GC, 
i can not tell what parts of the standard library can work 
without the GC. Even a simple output parsing gave me a compile 
error when running nogc a while ago.


When every new languages besides Rust or Zig are GC. That same 
"flaw" is not looked upon as a issue. It seems that D simply 
carries this GC stigma because the people mentioning are  C++ 
developers, the same people D targets as a potential user base.


D can have more success in targeting people from scripting 
languages like PHP, Ruby, Python, where the GC is not looked upon 
as a negative. The same effect can be seen in Go its popularity 
with drawing developers from scripting languages despite it not 
being there intention.


I always felt that D position itself as a higher language and in 
turn scares people away while at the same time the people it 
wants to attracts, with most are already set in there ways and 
looking at excuses to discredit D. The whole C++ has all of D 
features and does not need a GC / GC is bad excuse we see in the 
quora.com posting fits that description ( and not only there, 
also on other sites ).


If the GC issue can not be tackled and even with the recent 
communication blogs, it still keeps showing up. Is it maybe not 
better to focus the marketing features that 

template auto deduction

[Alex via Digitalmars-d-learn]

Hey, template gurus :)

given this:

struct M(alias I : S!E, alias S, E...)
{
R!E r;
this(S)(S initStruct)// line 4
{
r = R!E(initStruct);
}
}
struct R(E...)
{
this(S)(S initStruct)// line 12
{
// do some cool stuff
}
}
void main()
{
FS!(Etype1) fs;
auto m = M!(typeof(fs))(fs);// line 21.
auto a = M!(fs); // does not work
auto b = M(fs); // does not work
}
struct FS(T...){}
struct Etype1{}

Everything works as expected, especially line 21. The question is 
about syntactic sugar: What I have to change, to use auto 
deduction and to create the M struct like in line 22 or 23?


By the way, I'm aware, that the type matching in lines 4 and 12 
is lost, in the way it is written here. However, it is meant to 
exist, if this helps in some way...


Thanks a lot in advance
Alex

Re: Should we add `a * b` for vectors?

[jmh530 via Digitalmars-d]

On Friday, 6 October 2017 at 20:36:47 UTC, Jonathan M Davis wrote:


It forces them to actually be designed with the type and be 
easily located with the type. Would you want a programmer to be 
able to go and implement opBinary!"+" for strings? I sure 
wouldn't. And I don't want anyone doing that for user-defined 
types that they didn't define either.




Tangentially (I admit), there's nothing stopping you from below:

struct MyString
{
string mystring;
alias mystring this;
string opBinary(string op)(string rhs)
if(op == "+")
{
return mystring ~ rhs;
}
}

void main()
{
MyString x = MyString("foo");
string y = "bar";
auto z = x + y;
assert(z == "foobar");
}

Re: gdc is in

[Iain Buclaw via Digitalmars-d]

On 6 October 2017 at 22:34, John Colvin via Digitalmars-d
 wrote:
> On Friday, 6 October 2017 at 17:04:39 UTC, Iain Buclaw wrote:
>>
>> On 6 October 2017 at 17:21, jmh530 via Digitalmars-d
>>  wrote:
>>>
>>> On Friday, 6 October 2017 at 15:04:25 UTC, Joakim wrote:



 I assume you mean ddmd and static foreach, the mailing list post linked
 from my link implies it includes both.
>>>
>>>
>>>
>>> I would think this would be bigger news...I mean LDC isn't even on 2.076
>>> yet...
>>
>>
>>
>> Really?  Well, maintenance should be rather small now that the patch /
>> diff is relatively tiny for GDC.  Rebasing only against dmd/stable branch on
>> a weekly basis or so should help things along also.
>
>
> A lot of (most, even?) D users ignore GDC because it's been substantially
> behind the cutting edge for so long. Managing to catch up and become
> relevant to them is big news, if you want users.
>

I always assumed it was the license that put people off. ;-)

> To clarify: this includes Phobos, right?

Phobos is 2.076 as-is.  The compiler supports enough of the
feature-set, bug and regression fixes to compile the library and pass
the testsuite.

The switch from C++ to D(DMD) is still in a PR:
https://github.com/D-Programming-GDC/GDC/pull/550

Nothing is really blocking it, but it will go in a separate branch to
start off with.

Iain.

[Issue 17881] Provide mechanism to preallocate memory from the GC

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

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

--- Comment #3 from Andrei Alexandrescu  ---
>The use case is different than for GC.allocate.

The semi-joke was this is all needed.

>I want to fill in a structure of nodes, I know I'm going to fill it in with 
>10,000 elements, so I'm going to allocate them all in a loop. But I don't want 
>the GC to keep the ENTIRE thing in memory if just one element is still pointed 
>at. And I don't want to run the GC constantly in my tight loop allocating each 
>node.

The solution is to prefill a freelist, then let go of the extra elements
remaining.

>Think of a tree constructor, or an AA constructor.

>Essentially it's the same as array.reserve, but for individual blocks instead 
>of a contiguous single block.

That's not the job of the allocator. It's the job of the user of the allocator.
The allocator gives you memory. You organize it as you find fit.

--

[Issue 17881] Provide mechanism to preallocate memory from the GC

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

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

--- Comment #2 from Steven Schveighoffer  ---
The use case is different than for GC.allocate.

I want to fill in a structure of nodes, I know I'm going to fill it in with
10,000 elements, so I'm going to allocate them all in a loop. But I don't want
the GC to keep the ENTIRE thing in memory if just one element is still pointed
at. And I don't want to run the GC constantly in my tight loop allocating each
node.

Think of a tree constructor, or an AA constructor.

Essentially it's the same as array.reserve, but for individual blocks instead
of a contiguous single block.

--

Re: D on quora ...

[Laeeth Isharc via Digitalmars-d]

On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:


Why is GC a problem?


T



--
 Everybody talks about it, but nobody does anything about 
it!  -- Mark Twain**


Are you sure your quotes are randomly generated ??

Jonathan Davis wrote:
"We don't want D's standard library to rely on the GC when it 
doesn't need to, but there are language features that require it 
and really couldn't work with it, and there are cases where it's 
going to be involved by default for @safety reasons."


Perception is so important when people are making decisions about 
something they don't know.  (As Walter says, you have to write 
tens of sloc in a language to really see it's benefits.  They 
won't be so evident if you write D like the languages you know).


So I think the GC series has been very helpful.

But it might also be helpful to be very explicit on the functions 
that can and can't be called with nogc (I mean a top level 
overview in the docs) because it's one of the remaining sources 
of FUD that people say "yeah but you can't use large parts of the 
standard library without the GC".


And for things that are useful and easiest done with GC it would 
be nice to have an alternative that doesn't depend on the GC - if 
for no other reason than to address objections.  So the answer is 
then "yes - you're right, these X functions depend on the GC, but 
there are similar ones that don't".  (Walter already started that 
for functions that use the GC for purely legacy reasons but I 
mean for more difficult cases too.  I know Weka wrote their own 
versions of some std.algorithm functions for example).  Many 
things aren't much work, but when you have a lot to do, even 
small frictions can have big consequences.


So it's also a documentation question - it's not that easy from 
the outside last time I looked to see just how easy 
std.experimental.allocator is to use.

Re: Should we add `a * b` for vectors?

[Jonathan M Davis via Digitalmars-d]

On Friday, October 06, 2017 21:58:04 Timon Gehr via Digitalmars-d wrote:
> On 06.10.2017 00:04, Jonathan M Davis wrote:
> >> I'm very much in favor of this. Also, those rewrites should be
> >> consistently applied for all types, even built-ins (the compiler
> >> implementation can be more complex, but the language rules would be
> >> simplified).
> >> One immediate benefit would be that opCmp could be reliably used for
> >> all
> >> types that support comparison, for example 2.opCmp(3).
> >> Another benefit would be that operators such as += can reassign class
> >> references, for example when a value type is implemented as a unique
> >> reference to immutable data.
> >
> > Being able to do 2.opCmp(3) would be pretty cool, but I'm still
> > convinced
> > that allowing for operators to be overloaded outside of the type is a
> > terrible idea. It's far cleaner for them to be tied to the type
>
> It's far from clean because it enforces a certain calling convention.

It forces them to actually be designed with the type and be easily located
with the type. Would you want a programmer to be able to go and implement
opBinary!"+" for strings? I sure wouldn't. And I don't want anyone doing
that for user-defined types that they didn't define either.

> > - especially
> > when you consider that it's not possible to differentiate between
> > conflicting overloadeded operators.
>
> This is just not true. D has enough mechanisms for differentiating
> between conflicting overloads.

It isn't possible to differentiate when you do foo + bar, though I suppose
that it would then be possible to differentiate if you called
foo.opBinary!"+"(bar). However, that completely defeats the purpose of
overloaded operators.

> > And having them declared outside of the
> > type just opens up all of the problems that were just being complained
> > about in this thread with templated code not being able to access free
> > functions that weren't imported in the module that it's in.
>
> Those are UFCS issues, but I'd rather have UFCS than no UFCS.

And I'd rather never see operators overloaded by anything but the type
they're for.

- Jonathan M Davis

Re: gdc is in

[John Colvin via Digitalmars-d]

On Friday, 6 October 2017 at 17:04:39 UTC, Iain Buclaw wrote:
On 6 October 2017 at 17:21, jmh530 via Digitalmars-d 
 wrote:

On Friday, 6 October 2017 at 15:04:25 UTC, Joakim wrote:



I assume you mean ddmd and static foreach, the mailing list 
post linked from my link implies it includes both.



I would think this would be bigger news...I mean LDC isn't 
even on 2.076 yet...



Really?  Well, maintenance should be rather small now that the 
patch / diff is relatively tiny for GDC.  Rebasing only against 
dmd/stable branch on a weekly basis or so should help things 
along also.


A lot of (most, even?) D users ignore GDC because it's been 
substantially behind the cutting edge for so long. Managing to 
catch up and become relevant to them is big news, if you want 
users.


To clarify: this includes Phobos, right?

Re: dmd path handling is a bit dated

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, October 06, 2017 20:11:25 Laeeth Isharc via Digitalmars-d-learn 
wrote:
> And I'm posting here because we can submit a pull request, but I
> didn't know whether to call Phobos or copy/paste as I haven't
> submitted more than trivial doc changes to compiler.  I've
> written all of this up but on an internal gitlab.

dmd is not currently allowed to use Phobos, because they don't want that
dependency. But it shouldn't be a problem to copy over Phobos'
implementation of something where appropriate.

- Jonathan M Davis

Re: D on quora ...

[Jonathan M Davis via Digitalmars-d]

On Friday, October 06, 2017 17:14:51 Rion via Digitalmars-d wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
>
> It seems that D still has the GC being mentioned up to today.
>
> Maybe its better to move the standard library slower to a non gc
> version in the future...

D's GC isn't going anywhere. The implementation may be improved or replaced,
but there are huge advantages to having the GC (particularly with regards to
memory safety), and there _are_ actually times when using a GC is faster
than something like reference counting.

We don't want D's standard library to rely on the GC when it doesn't need
to, but there are language features that require it and really couldn't work
with it, and there are cases where it's going to be involved by default for
@safety reasons. For someone who wants to avoid the GC or minimize its use,
there are things that they will need to do (e.g. you have to be careful with
lambdas and probably use functors or functions, because closures are
frequently needed when dealing with lambdas, and that means using the GC;
@nogc will catch those cases for you so that you know when a lambda isn't
going to work). But while it should be possible for someone to avoid the GC
if they need to, that does not mean that we're looking to get rid of it or
even have not using it be the default. It just means that we don't want to
force its use where that doesn't make sense.

Honestly, I would _hate_ to use D without a GC. Without it, @safe memory
managament would not be possible, and you'd have to valgrind everything. As
it stands, you only have to do that when you have sections of @trusted code
that would potentially be a problem. And there's a lot of code that's
cleaner for not having to worry about managing memory.

That's not to say that using the GC is always better or that other solutions
are not more appropriate for some circumstances - and the fact that D gives
you control over a lot of that is fantastic - but this idea that GCs are
always nothing but bad and should be avoided by the plague is just nonsense.
GCs have their pros and cons, but they can be fantastic, and idiomatic D
programs actually mitigate a lot of the downsides that you can get with a
GC, because they do so much with the stack rather than the heap (which is
generally better performance-wise regardless of how heap allocations are
managed).

Yes, we could use a better GC, but overall, the GC is really just a PR
problem and not a real one. Most programs can use it and be plenty
performant. And those that can't have the tools necessary to minimize its
use or even outright avoid it (though honestly, if someone is looking to
outright avoid it, I'd lean towards wondering what the point of using D was
in the first place; the proponents of the -betterc stuff still think that
it's worth it though). Plenty of folks have managed to write performant
programs that involve D's GC.

- Jonathan M Davis

Re: dmd path handling is a bit dated

[Laeeth Isharc via Digitalmars-d-learn]

On Friday, 6 October 2017 at 20:11:25 UTC, Laeeth Isharc wrote:

DMD path handling is a bit dated, and it's causing build


I mean I imagine getcwd and tk/filespec.c might not be the only 
places that need updating, but I was going to start with those 
and see what happened.

dmd path handling is a bit dated

[Laeeth Isharc via Digitalmars-d-learn]

DMD path handling is a bit dated, and it's causing build problems 
for us because on Windows it's easy to end up breaking DMD's 
limit - particularly given how dub likes to turn everything into 
a relative path.


Windows has so many beautiful example of the costs of legacy 
compat.  I just wrote down 5 ways it handles paths, and then 
realised there's another.  There's a 260 char limit (less a bit, 
depending) in the old Windows API, but looking at the ddmd code 
there's a more restrictive limit of 131 chars + null for windows 
when it builds paths for the base directory.


I think if you use Windows 32 file namespaces (eg 
\?\C:\D\foo\bar, and note the difference from \?C\D\foo\bar ) and 
the unicode library calls then you get up to 32,767 chars.


We already have much better code in Phobos (for Windows it's 
hard-coded at 4K) getcwd, and I think either we should call 
Phobos or copy/paste the Phobos function into ddmd.


And I'm posting here because we can submit a pull request, but I 
didn't know whether to call Phobos or copy/paste as I haven't 
submitted more than trivial doc changes to compiler.  I've 
written all of this up but on an internal gitlab.


https://github.com/dlang/dmd/blob/2bf9a9d731e88ebd8a175bd0a990a3b651e8df82/src/ddmd/tk/filespec.c
(c) 1986-1987 by NorthWest Software.  It could do with an update!


"
So there's an obvious set of related problems.  Line 119 - 
current working dir is 131 chars + null.  and on linux it's 
restricted to 255+null (not sure if that limit applies anymore to 
linux, but who cares for now).


getcwd prototype is defined here:
https://github.com/dlang/dmd/blob/ebd6606840afea0034ce599815ed950fd558981c/src/ddmd/dmodule.d

and this is the prototype:
extern (C) char* getcwd(char* buffer, size_t maxlen);

it's deprecated and replaced by the ISO function:
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/getcwd-wgetcwd

okay - so:


it's wrong to use that limit on linux and OSX.  Linux PATH_MAX is 
4096.  OpenBSD is 1024.  Linux paths are unlimited, apparently 
(OSX can have several k chars at least).  And the Windows one 
should at least be PATH_MAX less a bit even without using long 
paths. (But then if you are going to use old winapi need to check 
its less than PATH_MAX if you extend).



https://insanecoding.blogspot.co.uk/2007/11/pathmax-simply-isnt.html


on Windows and indeed other operating systems we already have the 
correct code to get current working directory. so we just need to 
update dmd to use this.

https://github.com/dlang/phobos/blob/v2.076.0/std/file.d#L2681
"

[Issue 17881] Provide mechanism to preallocate memory from the GC

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

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
This seems like a tall order. It's essentially pushing a specific management
need on to the GC, complicating everyone's life in the process.

If an application needs to preallocate, there's an API for that already - it's
called GC.allocate() :o). Then the application needs to do its own bookkeeping.

--

Re: Proposal: Object/?? Destruction

[jmh530 via Digitalmars-d]

On Friday, 6 October 2017 at 19:51:39 UTC, Timon Gehr wrote:
No, under my thinking the original example should have been 
what it was.
Enclosing an expression in an additional set of parentheses 
does not change its semantics. This is true even if one set of 
parentheses is part of the function call.


Hmm, I hadn't realized that you can have multiple sets of 
parentheses without error. I was assuming you would treat the 
second set as a tuple.

Re: Should we add `a * b` for vectors?

[Timon Gehr via Digitalmars-d]

On 06.10.2017 00:04, Jonathan M Davis wrote:



I'm very much in favor of this. Also, those rewrites should be
consistently applied for all types, even built-ins (the compiler
implementation can be more complex, but the language rules would be
simplified).
One immediate benefit would be that opCmp could be reliably used for all
types that support comparison, for example 2.opCmp(3).
Another benefit would be that operators such as += can reassign class
references, for example when a value type is implemented as a unique
reference to immutable data.

Being able to do 2.opCmp(3) would be pretty cool, but I'm still convinced
that allowing for operators to be overloaded outside of the type is a
terrible idea. It's far cleaner for them to be tied to the type


It's far from clean because it enforces a certain calling convention.


- especially
when you consider that it's not possible to differentiate between
conflicting overloadeded operators.


This is just not true. D has enough mechanisms for differentiating 
between conflicting overloads.



And having them declared outside of the
type just opens up all of the problems that were just being complained about
in this thread with templated code not being able to access free functions
that weren't imported in the module that it's in.


Those are UFCS issues, but I'd rather have UFCS than no UFCS.

Re: D on quora ...

[SrMordred via Digitalmars-d]

On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
On Fri, Oct 06, 2017 at 06:09:58PM +, Ali via Digitalmars-d 
wrote:

On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
> On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via 
> Digitalmars-d wrote:

> > https://www.quora.com/What-is-your-review-of-D-programming-language
> > 
> > It seems that D still has the GC being mentioned up to 
> > today.
> > 
> > Maybe its better to move the standard library slower to a 
> > non gc version in the future...
> 
> Why is GC a problem?
> 
> 
> T


The reputation is D's GC is slow, and Manual Memory Management 
is fast


The first point is valid (when are we going to get a better GC? 
:-/), but the second is questionable.  But there's not much you 
can say to GC-phobic C/C++ aficiandos to convince them 
otherwise. (I used to be one of them.)



T


For me the important point is not directly about performance, but 
about determinism.
I know when the GC is called, and i can set when to collect, but 
I have no idea what they will do, how much memory they will free 
nor the time they will spent doing it. And this lack of control 
is the true problem.

Re: Proposal: Object/?? Destruction

[Timon Gehr via Digitalmars-d]

On 06.10.2017 21:43, jmh530 wrote:

On Friday, 6 October 2017 at 19:31:11 UTC, Timon Gehr wrote:
The proposal is to make all arguments "single type arguments". The 
"single type" might be a tuple. A tuple type is just a type, after 
all. For two current functions where only one matches but after the 
change both would match, the same one would still be selected, because 
it is more specialized.


[snip]
Then the call foo(2) will still go to the first overload and the call 
foo(1,2) will still go to the second overload, while the call 
foo(1,2,3) will still go to the third overload.



So under your thinking, the original example should have been something 
like:


---
auto id(T)(T x){ return x; }

void main(){
     auto a = id(2); // ok, a is 2.
     auto b = id(1,2); // error, b is not single type argument
     auto c = id(1,); // ok, c is 1.
     auto d = id((1,2)); // ok, d is (1,2)
     auto e = id((1,)); // ok, e is (1,)
}
---


No, under my thinking the original example should have been what it was.
Enclosing an expression in an additional set of parentheses does not 
change its semantics. This is true even if one set of parentheses is 
part of the function call.

Re: Proposal: Object/?? Destruction

[jmh530 via Digitalmars-d]

On Friday, 6 October 2017 at 19:31:11 UTC, Timon Gehr wrote:
The proposal is to make all arguments "single type arguments". 
The "single type" might be a tuple. A tuple type is just a 
type, after all. For two current functions where only one 
matches but after the change both would match, the same one 
would still be selected, because it is more specialized.


[snip]
Then the call foo(2) will still go to the first overload and 
the call foo(1,2) will still go to the second overload, while 
the call foo(1,2,3) will still go to the third overload.



So under your thinking, the original example should have been 
something like:


---
auto id(T)(T x){ return x; }

void main(){
auto a = id(2); // ok, a is 2.
auto b = id(1,2); // error, b is not single type argument
auto c = id(1,); // ok, c is 1.
auto d = id((1,2)); // ok, d is (1,2)
auto e = id((1,)); // ok, e is (1,)
}
---

Re: Proposal: Object/?? Destruction

[Timon Gehr via Digitalmars-d]

On 06.10.2017 14:26, Steven Schveighoffer wrote:

On 10/5/17 3:42 PM, Timon Gehr wrote:

On 05.10.2017 17:40, Steven Schveighoffer wrote:

On 10/5/17 2:42 AM, Timon Gehr wrote:

The only unresolved question is (as using the result of the comma 
operator has been deprecated already): How to write a unary tuple. 
My favourite is what python does: "(3,)". This is however already 
accepted as a function argument list. I think it is worth breaking 
though. Maybe we should deprecate it.


I know you have an answer for this, but pardon my ignorance.


I indeed have strong opinions on how to do this correctly, as I have 
given some thought to it when designing the (still quite basic) type 
system of PSI: https://github.com/eth-srl/psi


The idea is to follow type theory/mathematics where the type of 
functions is a binary type constructor taking domain and codomain to 
the type of functions mapping values from the domain to values from 
the codomain. Multiple function arguments are just the function 
applied to a tuple of values.



Why isn't (a) good enough?



typeof((a)) should be typeof(a). This is just a parenthesized 
expression, as in (a+b)*c.


Right, I agree.


typeof((a,)) should be (typeof(a),).


I guess my question is more in the context of the problem at hand:

int foo();

auto (a) = foo();

why can't this work?
...


This could be made to compile, but this is not really about tuples.

But then of course, it shouldn't work, because int is not a tuple. So I 
suppose I have answered my own question -- we need a way to specify a 
tuple of one for prototype foo!


Indeed, my experience with tuples and their usage is quite limited.

Even though the syntax is straightforward and unambiguous, it looks 
incorrect, like you forgot something.

...


That's not necessarily bad. (When is the last time you have used a 
singleton tuple?)


I'm not an expert in language design, but would it be worth exploring 
other punctuation that isn't used in the language currently to allow 
better syntax? It seems like the trailing comma is to get around 
ambiguity,


It's the comma that indicates tupling, so there is not really ambiguity, 
the expression (a) just is not a tuple. To indicate a tuple you need to 
use the tupling operator ','. Trailing commas are allowed for all 
tuples, but for singleton tuples they are also necessary.


but there would be no ambiguity if you used something other 
than current punctuation to surround the tuple.


Angle brackets come to mind .


D avoids angle brackets.

Also you could use a leading symbol to 
change the meaning of the parentheses, like $(a).

...


This is very noisy, and once you go with non-standard tuple syntax, you 
can just as well use tuple(a).



---
(int,) foo(int a){ return (a,); } // turn value into singleton tuple
int bar(int a,){ return a[0]; }   // turn singleton tuple into value

void main(){
 foo(2,); // error: cannot convert (int,) to int
 bar(2); // error: cannot convert int to (int,)
 auto (x,) = foo(2); // ok, x has type int
 auto y = bar(2,); // ok y has type int
 auto z = foo(2); // ok, z has type (int,)
}
---

---
// The following two function signatures are equivalent (identical 
name mangling):

(int,string) foo(int a,string b){
 return (a,b);
}

(int,string) foo((int,string) x){
 return x;
}
---


So I will ask, what is the usage of foo here?

In the first example (foo and bar), you can't call a function that takes 
a tuple with a single value, and you can't call a function that takes a 
value with a single tuple (BTW, this is not how AliasSeq works, you can 
call functions that take a single arg with single element tuples).

...


AliasSeq auto-expands. If you call a function with a single element 
AliasSeq, it will expand to a single value and not be an AliasSeq 
anymore. Built-in tuples should not auto-expand, so a singleton tuple 
stays a singleton tuple (they will have an explicit .expand property).


In your second example, where foo takes a 2-element tuple or 2 values, 


All functions take a single value. That value might be a tuple. (Of 
course, we will continue to say that a function can take multiple 
arguments, because it is convenient, but what this _means_ is that it 
takes a single tuple argument.)


you say the name mangling is equivalent. Does that mean if I only define 
the tuple version, I can call it with foo(1, "hello") and vice versa? 


Yes. (Both options are "the tuple version".)


This seems to contradict your example above.
...


No. All functions take one argument and produce one result. (The 
argument and the result may or may not be a tuple, but there is no 
essential difference between the two cases.) You can match a value 
against a pattern on the function call. The following are equivalent:


(int,string) foo(){
// unpack at initialization of local variables of `foo`
// pattern: (int a, string b)
// value:   (1,"2")
(int a, string b) = (1,"2");
return (a,b);
}

Re: D on quora ...

[H. S. Teoh via Digitalmars-d]

On Fri, Oct 06, 2017 at 06:09:58PM +, Ali via Digitalmars-d wrote:
> On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
> > On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via Digitalmars-d wrote:
> > > https://www.quora.com/What-is-your-review-of-D-programming-language
> > > 
> > > It seems that D still has the GC being mentioned up to today.
> > > 
> > > Maybe its better to move the standard library slower to a non gc
> > > version in the future...
> > 
> > Why is GC a problem?
> > 
> > 
> > T
> 
> The reputation is D's GC is slow, and Manual Memory Management is fast

The first point is valid (when are we going to get a better GC? :-/),
but the second is questionable.  But there's not much you can say to
GC-phobic C/C++ aficiandos to convince them otherwise. (I used to be one
of them.)


T

-- 
Today's society is one of specialization: as you grow, you learn more and more 
about less and less. Eventually, you know everything about nothing.

Re: For fun: Expressive C++ 17 Coding Challenge in D

[kerdemdemir via Digitalmars-d-learn]

I am a total beginner but I want to post that a lot.

auto autoCorrelation(R)(R range)
if (isRandomAccessRange!R)
{

import std.numeric : fft, inverseFft;
import std.range : chain, repeat, zip, dropBack;
import std.algorithm : map;
import std.complex;

auto residual = residualPowerOf2(range.length);
auto fftResult = range.chain(repeat(0, residual)).fft();
	auto autoCorrResult = fftResult.zip(fftResult.map!(a => 
a.conj())).

map!( a=> a[0] * a[1] ).
inverseFft().
dropBack(residual).
map!( a => a.re );

return autoCorrResult;
}   

I implemented auto correlation in C++ before which is I believe 
2~3 time bigger(also I needed to compile fftw, lapack etc.. ) :

https://forum.kde.org/viewtopic.php?f=74=118619 .

That was the moment I feel in love with D.

Need importing dcompute.lib into my project

[kerdemdemir via Digitalmars-d-learn]

Hi,

I have a cuda kernel already working in my cpp 
project(https://github.com/kerdemdemir/CUDABeamformer/blob/master/CudaBeamformer/kernel.cu)


I am trying to convert this to D with using DCompute. I already 
compiled the DCompute source code and have dcompute.lib. But I am 
really not good with using libraries and don't know how to use 
DCompute in my D 
project(https://github.com/kerdemdemir/DSharpEar/tree/master/DSharpEar). I am not using DUB and compiling with VisualD.


Can you guys please help with importing DCompute into my project?

Regards
Erdem

Re: D on quora ...

[Ali via Digitalmars-d]

On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via 
Digitalmars-d wrote:

https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non 
gc version in the future...


Why is GC a problem?


T


The reputation is D's GC is slow, and Manual Memory Management is 
fast

Re: D on quora ...

[H. S. Teoh via Digitalmars-d]

On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via Digitalmars-d wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
> 
> It seems that D still has the GC being mentioned up to today.
> 
> Maybe its better to move the standard library slower to a non gc
> version in the future...

Why is GC a problem?


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

D on quora ...

[Rion via Digitalmars-d]

https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non gc 
version in the future...

Re: gdc is in

[jmh530 via Digitalmars-d]

On Friday, 6 October 2017 at 17:04:39 UTC, Iain Buclaw wrote:



Really?  Well, maintenance should be rather small now that the 
patch / diff is relatively tiny for GDC.  Rebasing only against 
dmd/stable branch on a weekly basis or so should help things 
along also.


As long as I've been following D, GDC has been behind DMD for 
several releases. I would figure you would want to broadcast a 
bit more widely that you're caught up. It's good news, no?

Re: gdc is in

[Iain Buclaw via Digitalmars-d]

On 6 October 2017 at 17:21, jmh530 via Digitalmars-d
 wrote:
> On Friday, 6 October 2017 at 15:04:25 UTC, Joakim wrote:
>>
>>
>> I assume you mean ddmd and static foreach, the mailing list post linked
>> from my link implies it includes both.
>
>
> I would think this would be bigger news...I mean LDC isn't even on 2.076
> yet...


Really?  Well, maintenance should be rather small now that the patch /
diff is relatively tiny for GDC.  Rebasing only against dmd/stable
branch on a weekly basis or so should help things along also.

Re: gdc is in

[jmh530 via Digitalmars-d]

On Friday, 6 October 2017 at 15:04:25 UTC, Joakim wrote:


I assume you mean ddmd and static foreach, the mailing list 
post linked from my link implies it includes both.


I would think this would be bigger news...I mean LDC isn't even 
on 2.076 yet...

[Issue 17881] New: Provide mechanism to preallocate memory from the GC

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

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

  Issue ID: 17881
   Summary: Provide mechanism to preallocate memory from the GC
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

There are some times where you know you are going to allocate a bunch of blocks
from the GC, but you need to deal with them one at a time, and you don't want
them tied to one giant array for GC purposes.

A good example is an associative array:

int[int] aa;
foreach(i; 0 .. 20_000_000) aa[i] = i;

Each assignment requires a new GC allocation, which is unavoidable. However, we
could streamline the allocation:

1. If we told the GC that in the next few lines we were going to need 20
million AA elements of size X, it could set aside this data in a specialized
place that would not be collected, and would not be handed out elsewhere
(probably a new page bit is needed).
2. Each allocation for this purpose, until the preallocated cache is exhausted,
would simply return the next one, and not need to do any collections.
3. The GC could optimize locking. For instance it may only need to release for
possible collection the elements a page at a time, so only one lock/unlock when
it flips those bits. The idea is once you reserve, you plan to quickly use
those blocks.

A strawman high level API:

auto preallocate(T)(size_t quantity);

usage:

x = GC.preallocate!int(100_000); // give me a block of preallocated ints

foreach(i; 0 .. 100_000)
{
   assert(x.remaining + 1 + i == 100_000);
   int *p = x.allocNext(); // @nogc
}


When x goes out of scope, any remaining preallocated blocks that weren't used
are freed.

--

Re: gdc is in

[Joakim via Digitalmars-d]

On Wednesday, 4 October 2017 at 05:56:41 UTC, Per Nordlöw wrote:

On Tuesday, 3 October 2017 at 22:00:51 UTC, Joakim wrote:

On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:

the gcc tree:

https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Congratulations to Iain and the gdc team. :)

I found out because it's on the front page of HN right now, 
where commenters are asking questions about D.


An update, including the latest 2.076 frontend:

https://www.phoronix.com/scan.php?page=news_item=D-GCC-v3-Patches


Does this include DMD and static if?


I assume you mean ddmd and static foreach, the mailing list post 
linked from my link implies it includes both.

Re: Should we add `a * b` for vectors?

[Steven Schveighoffer via Digitalmars-d]

On 10/5/17 6:04 PM, Jonathan M Davis wrote:

On Thursday, October 05, 2017 13:36:23 Timon Gehr via Digitalmars-d wrote:

On 27 September 2017 at 17:41, Ilya Yaroshenko via Digitalmars-d
 wrote: I would prefer outer operator
overloading be added to D instead of type wrappers. So a user can
import a library for operations, rather then library of wrappers.
--Ilya

"outer operator overloading" is UFCS for operators. I.e.:

struct S{ int x; }
S opBinary(string op:"+")(S a,S b){ return S(a.x+b.x); }

void main(){
  auto s=S(3), t=S(4);
  import std.stdio;
  writeln(s+t); // S(7)
}

Starting from:

s+t

It rewritten to (as per the spec):
s.opBinary!"+"(t)

and then UFCS is applied (as per the spec):
opBinary!"+"(s,t)


I'm very much in favor of this. Also, those rewrites should be
consistently applied for all types, even built-ins (the compiler
implementation can be more complex, but the language rules would be
simplified).
One immediate benefit would be that opCmp could be reliably used for all
types that support comparison, for example 2.opCmp(3).
Another benefit would be that operators such as += can reassign class
references, for example when a value type is implemented as a unique
reference to immutable data.


Being able to do 2.opCmp(3) would be pretty cool, but I'm still convinced
that allowing for operators to be overloaded outside of the type is a
terrible idea. It's far cleaner for them to be tied to the type - especially
when you consider that it's not possible to differentiate between
conflicting overloadeded operators.


But UFCS already has all these "problems", and yet it's one of the most 
useful features of D.



And having them declared outside of the
type just opens up all of the problems that were just being complained about
in this thread with templated code not being able to access free functions
that weren't imported in the module that it's in.


That is a problem, but no different from any other UFCS scheme.

Indeed, providing a way to alias "official" UFCS functions into the 
namespace of the type itself would be useful.


-Steve

[Issue 17868] add pragma(crt_con/destructor)

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

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

--- Comment #9 from Steven Schveighoffer  ---
(In reply to Walter Bright from comment #8)
> What's the difference between this and `shared static this()` ?

This uses the C runtime's features to do static ctor/dtor (if the compiler
supports it), shared static this uses D's ModuleInfo to do it.

--

[Issue 17879] UFCS can enable some forms of hijacking

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #4 from Steven Schveighoffer  ---
According to the PR discussion, the issue was more like this:

mod1.d:
struct S {
// private string foo(){ return "hijacked"; }
}

main.d:
import mod1;

string foo(S s) { return "not hijacked"; }

void main() {
   S s;
   import std.stdio;
   writeln(s.foo());
}

In other words, the *private* symbol was hijacking UFCS. S should be able to
build whatever it wants privately without interfering with UFCS.

When I try to build this now, it doesn't work anyway. I get both a deprecation
warning and an error. I can't figure out why the original code that the PR was
fixing actually worked before the PR.

I agree with Jonathan that UFCS just doesn't take precedent over the member,
and can't be considered a hijacking. If we "fixed" this, for instance, any code
that used output ranges might break.

However, allowing UFCS to provide unrelated added methods that the type has the
same name for, should work.

--

Re: Should we add `a * b` for vectors?

[Steven Schveighoffer via Digitalmars-d]

On 10/5/17 3:40 PM, Walter Bright wrote:

On 10/5/2017 6:13 AM, Steven Schveighoffer wrote:

On 10/3/17 10:00 PM, Walter Bright wrote:

On 10/3/2017 5:24 PM, Steven Schveighoffer wrote:

It also can be cheaper to pass a small struct by value.


Should not be a problem if the compiler inlines it.


That's not always possible.


Right. But then the question becomes how much more complexity do we want 
to add chasing that last percent of perfection?


It all depends on how much you value convenience of operators. I can 
already do something like:


a.add(b);

which would "fix" the issue.



For example, right now I'm in my 3rd day of attempting to resolve

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

which is a regression brought about by layers and layers of fixes over 
time for a seemingly simple issue - implicitly converting a unique 
return from a pure function into an immutable.


For another example, it took Martin and I months to implement the new 
import lookup scheme. It turned out to be fairly complicated, and there 
were many regressions. There are probably still issues lurking in it.


The import changes modified how existing code worked. This is not the 
same thing. Of course you need to take more care of features that are 
going to break a lot of projects and make sure they don't. I spent a 
long time fixing the cycle detection, but had to figure out a way to do 
it such that it allowed people to use the old broken detection if they 
wanted to. That was not an easy thing to do, and took about 4 iterations.


We need to keep the language rules simple enough to understand and 
simple enough to implement, and there will be compromises with that.


I understand, and agree. I was just noting one reason why allowing 
operator overloading outside the type itself could be useful. It doesn't 
even have to be full-blown UFCS, it could be as simple as aliasing a 
member to an external function, which doesn't require any new changes to 
lookup rules.


In addition, inlining doesn't get around certain requirements for 
calling (e.g. the nice property of being able to implicitly cast away 
const).


-Steve

Re: Should we add `a * b` for vectors?

[jmh530 via Digitalmars-d]

On Friday, 6 October 2017 at 10:56:06 UTC, Guillaume Boucher 
wrote:


Knowing which function is called when we see its name is very 
important for reading code.  That's why we have those anti 
hijacking rules: they disallow cases where the compiler knows 
that the call can be misleading (or can silently break existing 
code).  Another, more tricky case is when there are two 
functions with the same name in the project you are working on, 
but only one of them is being imported.  If you read the code, 
you are unsure which one is called.  The anti-hijacking rules 
won't work in that case.
Fortunately, a good naming scheme avoids those problems so they 
are not a big problem in practice.




With respect to overloaded operators, I was trying to make the 
point above that the anti-hijacking would stay in place. If you 
wanted to offer two different options for operators, you could 
put them in separate modules so that you could import one or the 
other, but not both (which should give an error). I admit it's 
not super convenient, but it's an option.

Re: Proposal: Object/?? Destruction

[Steven Schveighoffer via Digitalmars-d]

On 10/5/17 3:42 PM, Timon Gehr wrote:

On 05.10.2017 17:40, Steven Schveighoffer wrote:

On 10/5/17 2:42 AM, Timon Gehr wrote:

The only unresolved question is (as using the result of the comma 
operator has been deprecated already): How to write a unary tuple. My 
favourite is what python does: "(3,)". This is however already 
accepted as a function argument list. I think it is worth breaking 
though. Maybe we should deprecate it.


I know you have an answer for this, but pardon my ignorance.


I indeed have strong opinions on how to do this correctly, as I have 
given some thought to it when designing the (still quite basic) type 
system of PSI: https://github.com/eth-srl/psi


The idea is to follow type theory/mathematics where the type of 
functions is a binary type constructor taking domain and codomain to the 
type of functions mapping values from the domain to values from the 
codomain. Multiple function arguments are just the function applied to a 
tuple of values.



Why isn't (a) good enough?



typeof((a)) should be typeof(a). This is just a parenthesized 
expression, as in (a+b)*c.


Right, I agree.


typeof((a,)) should be (typeof(a),).


I guess my question is more in the context of the problem at hand:

int foo();

auto (a) = foo();

why can't this work?

But then of course, it shouldn't work, because int is not a tuple. So I 
suppose I have answered my own question -- we need a way to specify a 
tuple of one for prototype foo!


Indeed, my experience with tuples and their usage is quite limited.

Even though the syntax is straightforward and unambiguous, it looks 
incorrect, like you forgot something.


I'm not an expert in language design, but would it be worth exploring 
other punctuation that isn't used in the language currently to allow 
better syntax? It seems like the trailing comma is to get around 
ambiguity, but there would be no ambiguity if you used something other 
than current punctuation to surround the tuple.


Angle brackets come to mind . Also you could use a leading symbol to 
change the meaning of the parentheses, like $(a).



---
(int,) foo(int a){ return (a,); } // turn value into singleton tuple
int bar(int a,){ return a[0]; }   // turn singleton tuple into value

void main(){
     foo(2,); // error: cannot convert (int,) to int
     bar(2); // error: cannot convert int to (int,)
     auto (x,) = foo(2); // ok, x has type int
     auto y = bar(2,); // ok y has type int
     auto z = foo(2); // ok, z has type (int,)
}
---

---
// The following two function signatures are equivalent (identical name 
mangling):

(int,string) foo(int a,string b){
     return (a,b);
}

(int,string) foo((int,string) x){
     return x;
}
---


So I will ask, what is the usage of foo here?

In the first example (foo and bar), you can't call a function that takes 
a tuple with a single value, and you can't call a function that takes a 
value with a single tuple (BTW, this is not how AliasSeq works, you can 
call functions that take a single arg with single element tuples).


In your second example, where foo takes a 2-element tuple or 2 values, 
you say the name mangling is equivalent. Does that mean if I only define 
the tuple version, I can call it with foo(1, "hello") and vice versa? 
This seems to contradict your example above.



---
auto id(T)(T x){ return x; }

void main(){
     auto a = id(2); // ok, a is 2.
     auto b = id(1,2); // ok, b is (1,2)
     auto c = id(1,); // ok, c is (1,)
}
---



This would mess up a TON of code. I can say for certain, a single type 
argument can never be made to accept a tuple.


-Steve

Re: Should we add `a * b` for vectors?

[Guillaume Boucher via Digitalmars-d]

On Thursday, 5 October 2017 at 22:04:10 UTC, Jonathan M Davis 
wrote:
It's far cleaner for them to be tied to the type - especially 
when you consider that it's not possible to differentiate 
between conflicting overloadeded operators.


In other words, we lose global uniqueness of operators if we were 
to allow free functions to implement operators.


Knowing which function is called when we see its name is very 
important for reading code.  That's why we have those anti 
hijacking rules: they disallow cases where the compiler knows 
that the call can be misleading (or can silently break existing 
code).  Another, more tricky case is when there are two functions 
with the same name in the project you are working on, but only 
one of them is being imported.  If you read the code, you are 
unsure which one is called.  The anti-hijacking rules won't work 
in that case.
Fortunately, a good naming scheme avoids those problems so they 
are not a big problem in practice.


Those problems will pop up, however, if we allow them for 
operators.  Without further regulations, different 
implementations for operators are almost guaranteed, which will 
lead to uncertainty and distrust in code using operators.




Besides, I don't how it should work without changes to lookup 
rules.  How should sum() be able to use a +-operator defined in 
an imported module?  Not even ADL is helping here.


In my opinion, operators should only be defined in the module 
defining the type.

Facebook customer service number? It's a trick

[andrew taylor via Digitalmars-d]

More than likely, you are one of the billions of dynamic Facebook 
customer. The truth is out, billions! It's assessed that there 
are almost 2 billion dynamic month to month customer around the 
world.


With that many individuals taking an interest on the online 
networking webpage, issues will undoubtedly emerge. On the off 
chance that something did turn out badly, how might you contact 
Facebook? You truly should be watchful in endeavouring to reach, 
it could bring about a dreadful trick.


A few people as of late recorded reports with police about being 
misled while endeavouring to contact Facebook. NPR chose to 
investigate what's happening.


NPR had an organization that spends significant time in phone 
misrepresentation call the number. The individual who addressed 
the call guaranteed to be a Facebook agent however was really a 
fake.


Here's the way the call went:
The fraudster addressed the phone by saying, "A debt of gratitude 
is in order for calling Facebook." The scientist told the phony 
rep that he was bolted out of his Facebook account and required 
help getting back in.


The con artist said for the record to be opened, the specialist 
expected to go to either Target or Walmart and purchase an iTunes 
card. When he bought the iTunes card, he was to get back to and 
give the fraudster the 16-digit security code situated on the 
back of the card. He would then be given the Password to open the 
Facebook account.


Step by step instructions to contact Facebook

The phone number that NPR found on Google likewise turned up in 
different places over the previous year. It was notwithstanding 
flowing on Facebook itself, on specific pages where individuals 
request offer assistance.


What you truly need to know is that there is No telephone number 
to contact Facebook. An individual from the organization's Help 
Team made that declaration on one of the pages that a customer 
was requesting help.


So on the off chance that you do an online look for Facebook 
client benefit, don't call any number that appears in the 
outcomes. The main way you can really contact Facebook is through 
its assistance focus.


facebookhelpdotus

Re: Infuriating DUB/DMD build bug.

[Mike Parker via Digitalmars-d-learn]

On Friday, 6 October 2017 at 09:12:09 UTC, Mike Parker wrote:

On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:


AppData/Roaming/dub/packages, create a new directory off C: 
(say, C:\dub, manually fetch the packages you need into that 
directory and use `dub add-local` on them (see an example in 
the derelict docs [1]), then try to build your project again 
and see what happens.


[1] 
http://derelictorg.github.io/building/without-dub/#fetching-packages-with-dub

Re: Infuriating DUB/DMD build bug.

[Mike Parker via Digitalmars-d-learn]

On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:

With writing files, that's usually a permissions thing?  But 
all the other 8 packages build fine?


Note: I had a similar problem with derelict-assimp3 package, so 
I went to an entirely different system and cloned my project.  
But now it fails with the same error, but with

a different package.


Looks like it may be a system error as a result of the path being 
too long. I've encountered that a couple times over the years 
when building projects with dub. What I suggest you try is to 
remove the offending package(s) from 
AppData/Roaming/dub/packages, create a new directory off C: (say, 
C:\dub, manually fetch the packages you need into that directory 
and use `dub add-local` on them (see an example in the derelict 
docs [1]), then try to build your project again and see what 
happens.