On Sat., 21 Jul. 2018, 12:30 pm Johnatune via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> I was for this back when it was only for 'const ref' but that
> somehow changed to just ref. Which I think is a mistake. Yes D's
> const is broken and useless, but I don't think that's a reason to
I was for this back when it was only for 'const ref' but that
somehow changed to just ref. Which I think is a mistake. Yes D's
const is broken and useless, but I don't think that's a reason to
introduce difficult to locate bugs with the addition of this
feature. There's not a simple way to
On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote:
Frankly speaking, my feeling is that D is becoming a horrible
mess for the programmer...
/Paolo
How!? Please Explain. You need to demonstrate evidence instead of
appeal to emotional fallacy by resorting to "feels".
https://issues.dlang.org/show_bug.cgi?id=15246
--- Comment #19 from alexanderheisterm...@gmail.com ---
PhotoObject does not solve this issue, as it involved predefined functions
toString, toHash, opCmp, and opEquals.
See this link:
https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIP.md
So I went to try out QWebView on Windows from this wrapper:
https://github.com/MGWL/QtE5
all the examples went fine until I tried QWebView:
https://github.com/MGWL/QtE5/blob/master/examples/webview.d
I compile using this command line:
dmd -m32 webview.d qte5.d -oflol
but when I run I get
I know this one year old already but the DIP is still in formal
review.
I Think the inability to create a delegate with a custom object
as its context similar to delegates created from member functions
should be fixed in a library solution rather than making a
language change. A simple
On Friday, 20 July 2018 at 14:03:20 UTC, bachmeier wrote:
Yeah, I didn't need the symlink on a different machine with
Ubuntu 18.04. After some digging around, I found that I had
libclang1-3.9, libclang-dev, and libclang-common-3.9-dev
installed. libclang1-3.9 installs libclang.so.1. The one I
On Saturday, 21 July 2018 at 12:54:28 UTC, JohnB wrote:
On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi
wrote:
Frankly speaking, my feeling is that D is becoming a horrible
mess for the programmer...
I'm starting to think that only a D3, with a lot of thing
reorganised without
On Saturday, 21 July 2018 at 13:13:11 UTC, Mike Parker wrote:
On Saturday, 21 July 2018 at 12:17:54 UTC, Greatsam4sure wrote:
Sorry for the typo. This is the problem
auto arithmetic(T, V, U)(T a, V b, U op){
return mixin("a"~op~"b");
}
//call like this
arithmetic(1.5,2.5,"+");
On Friday, 20 July 2018 at 16:37:24 UTC, Seb wrote:
On Friday, 20 July 2018 at 15:33:19 UTC, Radu wrote:
On Thursday, 19 July 2018 at 18:16:17 UTC, kinke wrote:
I'll go with Seb's suggestion and look at the betterC tests
upstream for issues like this.
FYI: I made a reboot of the old PR to a
https://issues.dlang.org/show_bug.cgi?id=17390
Vic Luo changed:
What|Removed |Added
CC||viclu...@gmail.com
--
On Saturday, 21 July 2018 at 12:17:54 UTC, Greatsam4sure wrote:
Sorry for the typo. This is the problem
auto arithmetic(T, V, U)(T a, V b, U op){
return mixin("a"~op~"b");
}
//call like this
arithmetic(1.5,2.5,"+");
Compiler says the variable op is not reach at compile time. So
how
On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote:
Frankly speaking, my feeling is that D is becoming a horrible
mess for the programmer...
I'm starting to think that only a D3, with a lot of thing
reorganised without the obsession of breaking changes can safe
that beautiful
On 22/07/2018 12:15 AM, Greatsam4sure wrote:
auto arithmetic(T, V, U)(T a, V b, U op){
return mixin("a"~op~"b");
}
//call like this
arithmetic(1.5,2.5,"op");
Compiler says the variable op is not reach at compile time. So how can
the varible a and b be reach at compile time and op is
Sorry for the typo. This is the problem
auto arithmetic(T, V, U)(T a, V b, U op){
return mixin("a"~op~"b");
}
//call like this
arithmetic(1.5,2.5,"+");
Compiler says the variable op is not reach at compile time. So
how can the varible a and b be reach at compile time and op is
not
auto arithmetic(T, V, U)(T a, V b, U op){
return mixin("a"~op~"b");
}
//call like this
arithmetic(1.5,2.5,"op");
Compiler says the variable op is not reach at compile time. So
how can the varible a and b be reach at compile time and op is
not reach. I will appreciate any help. I have
On Sunday, 15 July 2018 at 19:46:24 UTC, kinke wrote:
Glad to announce the second beta for LDC 1.11.
* Based on D 2.081.1+ (today's DMD stable).
* Prebuilt packages now using LLVM 6.0.1 and including
additional cross-compilation targets (MIPS, MSP430, RISC-V and
WebAssembly).
* Rudimentary
Thanks a lot, Manu, I'm a huge fan of this.
Wrt. binding rvalues to mutable refs, we could introduce
something like `-transition=rval_to_mutable_ref` to have the
compiler list all matching call sites.
Wrt. `auto ref`, I'd very much like to see its semantics change
to 'pass this argument in
https://issues.dlang.org/show_bug.cgi?id=19104
Issue ID: 19104
Summary: Multiple overload resolution match when using default
arguments
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
On Friday, 20 July 2018 at 23:19:08 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 16:39:46 UTC, Dukc wrote:
How so? It could be made it act exactly as if the temporary
was made just before the function call, meaning the lifetime
would end at the end of current scope.
... which is
On Saturday, 21 July 2018 at 05:40:24 UTC, Nicholas Wilson wrote:
It is not just the avoiding copying, if it were I'm not sure
I'd support it. For me the greatest benefit is the increase in
readability due to not having useless temporaries everywhere in
ref heavy code (that may not be under
On Sat, 21 Jul 2018 at 00:15, Johannes Loher via Digitalmars-d
wrote:
>
> On Saturday, 21 July 2018 at 05:59:37 UTC, Manu wrote:
> > [...]
>
> Let me give a concrete example of one of the situations Jonathan
> is describing. Consider the following code:
>
>
> struct Secret
> {
> public:
>
On Saturday, 21 July 2018 at 07:10:51 UTC, Johannes Loher wrote:
[...]
By the way, this does not mean I am totally against DIP 1016. It
has a lot of benefits in my opinion. But I also think that
Jonathan has a very valid point which definitely needs to be
considered.
On Saturday, 21 July 2018 at 05:59:37 UTC, Manu wrote:
[...]
Let me give a concrete example of one of the situations Jonathan
is describing. Consider the following code:
struct Secret
{
public:
string key;
}
/* ... */
genrateRandomKey(ref string key) {
key = /* some code to
https://issues.dlang.org/show_bug.cgi?id=19099
--- Comment #1 from Walter Bright ---
https://github.com/dlang/dmd/pull/8507
--
https://issues.dlang.org/show_bug.cgi?id=19099
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
On Fri, 20 Jul 2018 at 22:45, Nicholas Wilson via Digitalmars-d
wrote:
>
> On Saturday, 21 July 2018 at 04:09:25 UTC, Jonathan M Davis wrote:
> > Honestly, I think we're just coming from points of view that
> > are too different. IMHO, the core use case for ref is for a
> > function to mutate an
27 matches
Mail list logo
