[Issue 16086] Imported function name shadows alias this member

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
The trouble is it is picking up std.range.tail rather than the alias this.

--

[Issue 14648] DIP25's "return" attribute breaks safety checks

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
The code in question:

// rdmd -unittest -main -dip25 dip25.d 

private struct Container 
{ 
this(int c) @safe 
{ 
arr = new int[](c); 
arr[] = c; 
} 

 ~this() @safe 
 { 
 arr[] = -1; 
 } 

 ref Range opSlice() return @safe // remove "return" and this code
correctly fails to compile 
 { 
 r.index = 0; 
 r.c =  
 return r; 
 } 

 @safe struct Range 
 { 
 int front() { return c.arr[index]; } 
 bool empty() { return index >= c.arr.length; } 
 void popFront() { index++; } 
 size_t index; 
 Container* c; 
 } 

 private: 
 Range r; 
 int[] arr; 
 } 

 private struct S 
 { 
 void takesContainer(ref Container c) @safe 
 { 
 this.r = c[]; 
 } 

 void print() @safe 
 { 
 import std.stdio:writeln; 
 writeln(r); 
 } 

 Container.Range r; 
 } 

 void doStuff(ref S s) @safe 
 { 
 auto c = Container(20); 
 s.takesContainer(c); 
 } 

 @safe unittest 
 { 
 S s; 
 doStuff(s); 
 s.print(); 
 }

--

[Issue 13940] std.algorithm.argMin

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

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

--- Comment #7 from greenify  ---
Min and maxElement are part of Phobos since 2.071 - the crowd goes wild :) 
They support a custom mapping function and evaluation of the mapping is only
done once.

--

[Issue 16133] New: core.sys.windows.oleidl.IOleInPlaceSite definition is incorrect

[via Digitalmars-d-bugs]

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

  Issue ID: 16133
   Summary: core.sys.windows.oleidl.IOleInPlaceSite definition is
incorrect
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: johnch_a...@hotmail.com

Namely, the GetWindowContext member should be:

HRESULT
GetWindowContext(IOleInPlaceFrame*,IOleInPlaceUIWindow*,LPRECT,LPRECT,LPOLEINPLACEFRAMEINFO);

--

[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends

[via Digitalmars-d-bugs]

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

--- Comment #12 from Steven Schveighoffer  ---
(In reply to Dmitry Olshansky from comment #11)
> > At this point, if we were to fix purity, I think this is the way to go. 
> > From your comments in the code, you said that most of the time allocations 
> > will not happen. I'm sure this varies with the language being processed, 
> > but it's probably mostly true.
> 
> Problem is there is @nogc crowd and then there is pure @safe crowd. I can't
> satisfy both.

Haha! good point. Until we have allocator being configurable, we can't solve
both.

I say leave it the way it is until we have that. @nogc is currently way more
important than purity I think, and breaking existing @nogc code by making the
default all of a sudden use gc, would be disruptive.

--

[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends

[via Digitalmars-d-bugs]

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

--- Comment #11 from Dmitry Olshansky  ---
> At this point, if we were to fix purity, I think this is the way to go. From 
> your comments in the code, you said that most of the time allocations will 
> not happen. I'm sure this varies with the language being processed, but it's 
> probably mostly true.

Problem is there is @nogc crowd and then there is pure @safe crowd. I can't
satisfy both.

--

[Issue 16123] alias member of member

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #7 from Steven Schveighoffer  ---
(In reply to Max Samukha from comment #5)
> I just say that what you are trying is not how 'alias' works, and the
> current semantics does make sense. Whether it is good is a different issue.

However, I get your point that this is intended behavior and working as
designed. I'm changing to enhancement.

--

[Issue 16123] alias member of member

[via Digitalmars-d-bugs]

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

--- Comment #6 from Steven Schveighoffer  ---
(In reply to Max Samukha from comment #5)
> (In reply to Steven Schveighoffer from comment #4)
> > I'm having trouble seeing how this logically is different. Access to t.s.x
> > is done by adding some offset to , just like access to s.x is done by
> > adding some offset to 
> > 
> > I get that the "symbol" I'm trying to alias is really a compound symbol, but
> > I can alias it just fine in other places.
> 
> I just say that what you are trying is not how 'alias' works, and the
> current semantics does make sense. Whether it is good is a different issue.

I would understand if s was a property and not a field, because you need to
execute code to compute the actual access. I get that alias is not as powerful
as a mixin, but this doesn't seem like a reasonable limitation.

Note: it's kind of weird that the compiler would allow this kind of alias to
compile when it's fully unusable.

> > This reminds me of the whole inability to alias keywords. It's an
> > implementation detail that I shouldn't have to care about!
> 
> Inability to alias keywords is a different issue.

To the user, it's not much different. Granted, two different implementation
issues, but it looks the same -- compiler cannot do what should be obviously
doable.

--

[Issue 16123] alias member of member

[via Digitalmars-d-bugs]

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

--- Comment #5 from Max Samukha  ---
(In reply to Steven Schveighoffer from comment #4)
> I'm having trouble seeing how this logically is different. Access to t.s.x
> is done by adding some offset to , just like access to s.x is done by
> adding some offset to 
> 
> I get that the "symbol" I'm trying to alias is really a compound symbol, but
> I can alias it just fine in other places.

I just say that what you are trying is not how 'alias' works, and the current
semantics does make sense. Whether it is good is a different issue.

> 
> This reminds me of the whole inability to alias keywords. It's an
> implementation detail that I shouldn't have to care about!

Inability to alias keywords is a different issue.

--

[Issue 16123] alias member of member

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
I'm having trouble seeing how this logically is different. Access to t.s.x is
done by adding some offset to , just like access to s.x is done by adding
some offset to 

I get that the "symbol" I'm trying to alias is really a compound symbol, but I
can alias it just fine in other places.

This reminds me of the whole inability to alias keywords. It's an
implementation detail that I shouldn't have to care about!

--

[Issue 16123] alias member of member

[via Digitalmars-d-bugs]

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

Max Samukha  changed:

   What|Removed |Added

 CC||maxsamu...@gmail.com

--- Comment #3 from Max Samukha  ---
(In reply to Steven Schveighoffer from comment #2)
> (In reply to Sobirari Muhomori from comment #1)
> 
> > struct T
> > {
> >S s;
> >alias y = S.x; // what this means?
> > }
> 
> Right, but I said s.x, not S.x. It means alias to the member x of the
> instance of S called s, which resides in this instance of T.

In 'alias', they are just two equivalent ways of referencing 'x', that is:

__traits(isSame, S.x, T.s.x) == true

And it kind of makes sense if you think of 'alias' as little more than a means
of creating synonyms for a symbol. With 's.x' in the 'alias' declaration, you
are simply importing 'x' to the namespace of 'T'. Not that I care much now, but
some code I wrote actually relied on this semantics.

--

[Issue 16123] alias member of member

[via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
(In reply to Sobirari Muhomori from comment #1)

> struct T
> {
>S s;
>alias y = S.x; // what this means?
> }

Right, but I said s.x, not S.x. It means alias to the member x of the instance
of S called s, which resides in this instance of T.

Maybe it's more helpful if I say:

alias y = T.s.x;

In any case, I see no technical limitation of why this shouldn't work. If
there's already a way to do it, please close and let me know how to!

Note, I've worked around in my code by doing essentially:

private ref y() { return s.x; }

But I much prefer the alias mechanism.

--

[Issue 16123] alias member of member

[via Digitalmars-d-bugs]

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

--- Comment #1 from Sobirari Muhomori  ---
I guess, you can alias a symbol, but then the compiler doesn't know what S's
symbol in T struct means.

struct S
{
   int x;
   alias y = x;
}

actually means

struct S
{
   int x;
   alias y = S.x;
}


struct T
{
   S s;
   alias y = S.x; // what this means?
}

--

[Issue 16109] replace all UL/LI code with markdown syntax

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #2 from Jack Stouffer  ---
This was debated in this thread:
http://forum.dlang.org/post/uthwzyarohikwkjha...@forum.dlang.org

--

[Issue 14943] dmd should inline more aggressively

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 14943] dmd should inline more aggressively

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Jack Stouffer  ---
*** Issue 16120 has been marked as a duplicate of this issue. ***

--

[Issue 16120] dmd does not inline simple range primitives

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |DUPLICATE

--- Comment #1 from Jack Stouffer  ---


*** This issue has been marked as a duplicate of issue 14943 ***

--

[Issue 16131] A struct is being copied unnecessarily when initialized

[via Digitalmars-d-bugs]

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

--- Comment #1 from Sobirari Muhomori  ---
I'd say it's moved. It was said many times that move semantics exists in D, but
nothing about that is documented :(

--

[Issue 16132] New: std.variant.VariantN does not work with a class that inherits from a template instantiation

[via Digitalmars-d-bugs]

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

  Issue ID: 16132
   Summary: std.variant.VariantN does not work with a class that
inherits from a template instantiation
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: gmane...@hotmail.com

The following code does not compile. The error is:
../src/phobos/std/variant.d(546,9): Error: static assert  "Cannot store a C in
a VariantN!(8LU, C)"


   interface I(T) {
   }

   class C : I!int {
   }

   auto c = new C;
   Algebraic!C a = c;


Most probably the cause is how AllowedTypes is determined. It uses
std.typecons.ReplaceType to replace This with VariantN.

Here is a short repro of the cause:

   import std.typecons;
   static assert(is(ReplaceType!(int, string, C) == I!string));

So the type C is replaced with I!int in VariantN.AllowedTypes.

--

[Issue 12575] extern(C) mangling ignored inside mixin template

[via Digitalmars-d-bugs]

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

det <2k...@gmx.net> changed:

   What|Removed |Added

 CC||2k...@gmx.net

--

[Issue 16108] `to!string` fails on struct with disabled postblit

[via Digitalmars-d-bugs]

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

Eyal  changed:

   What|Removed |Added

 CC||e...@weka.io

--- Comment #1 from Eyal  ---
This seems related #9489.

Fixing this should probably involve overloading all the relevant methods in
std.conv to support taking by ref as well as by-value.

--

[Issue 16131] New: A struct is being copied unnecessarily when initialized

[via Digitalmars-d-bugs]

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

  Issue ID: 16131
   Summary: A struct is being copied unnecessarily when
initialized
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Even when the struct disallows copying, it is being temporarily created and
copied. This reproduces on both dmd and ldc2.

Reproducing example:

struct Foo {
@disable this(this);
this(out Foo *x) { x =  }
}

void main() {
Foo *x;
auto a = Foo(x);
assert(x == ); // OK
Foo b;
b = Foo(x);
assert(x == ); // FAILS
}

--