[Issue 16243] wrong C++ argument passing with empty struct and 6 integers

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||bra...@puremagic.com

--- Comment #7 from Martin Nowak  ---
(In reply to kinke from comment #4)
> clang doesn't pass empty structs at all for 32-bit, while GCC does. We have
> such a special case in LDC too for 32-bit OSX, where we assume clang, but
> not for 32-bit Linux, where we assume GCC. See
> https://github.com/ldc-developers/ldc/blob/master/gen/abi-x86.cpp#L214.

Thanks, assuming clang by default on OSX indeed seems like a reasonable
solution.
We also have that issue with GCC5's C++ ABI change
(http://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/), so
detecting the actual compiler might be helpful as well.

(In reply to Jacob Carlborg from comment #6)
> There's a long time since Apple switched to Clang. GCC is dead on Apple
> platforms. I've mentioned this several times that the autotester should
> switch to Clang.

Yes, would be good if we updated the auto-testers to use clang @Brad.

--

[Issue 16086] Imported function name shadows alias this member

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Priority|P1  |P2
   Severity|regression  |normal

--- Comment #2 from Martin Nowak  ---
This issue is not a result of the lookup change, but happens because tail was
newly added to std.range in 2.071.x.
Alias this and opDispatch was and still is resolved after an exhaustive search.
Might be worthwhile to think about performing alias this resolution before
searching imported modules, to avoid such breakage due to upstream library
changes.

--

[Issue 15897] private base class method not seen through derived class

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||renezwanenb...@gmail.com

--- Comment #20 from Martin Nowak  ---
*** Issue 15983 has been marked as a duplicate of this issue. ***

--

[Issue 15983] [REG 2.071] Symbol visibility in derived classes

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Nowak  ---
You can get the base class like so.

void foo(T)(T t) if (is(T Base == super))
{
Base.Something something;
}

Still need to have all base classes in a the same module/package as the
function.
Would be interested to know, why you rely on duck typing of the base class.
Also maybe it's not worth to hide Something when it's a common property of your
class hierarchy.

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

--

[Issue 15897] private base class method not seen through derived class

[via Digitalmars-d-bugs]

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

--- Comment #19 from Martin Nowak  ---
(In reply to Sophie from comment #18)
> Isn't this what the "protected" access modifier is for?

Yes, protected would be the choice for inheriting a function.

Here the question was whether a private member of a base class, should be
visible for derived classes in the base class' module. Not revealing that
private member, b/c the derived class is in a different module, is a semantic
change introduced by DIP22, hence the deprecation.

--

[Issue 15903] [REG 2.071] module foo.bar is not accessible here, perhaps add 'static import foo.bar; (already there)

[via Digitalmars-d-bugs]

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

--- Comment #7 from Martin Nowak  ---
(In reply to Martin Nowak from comment #6)
> Comment 3 is clearly a duplicate of issue 15000.

issue 15900

--

[Issue 15903] [REG 2.071] module foo.bar is not accessible here, perhaps add 'static import foo.bar; (already there)

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All

--- Comment #6 from Martin Nowak  ---
Can't reproduce the issues of comment 0 and comment 4, please retest and
provide a complete test case.
Comment 3 is clearly a duplicate of issue 15000.

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Reduced to the core:


struct TestType(T) {}
alias TestAlias(T) = TestType!T;
void testFunction(T)(TestAlias!T arg) {}

void main()
{
TestAlias!int testObj;
testFunction(testObj); /* "cannot deduce function from argument types
!()(TestType!int)" */
}


I don't think this is supposed to work.

It works when testFunction's parameter is TestType!T, because testObj's type
(TestType!int/TestAlias!int) carries the information that it's an instantiation
of template TestType with argument int.

But the compiler has no simple way of telling how TestType!int relates to
TestAlias!T. For example, TestAlias could be defined like this:


template TestAlias(T)
{
static if (is(T == float)) alias TestAlias = TestType!int;
else alias TestAlias = string;
}


With that, testFunction(TestType!int.init) would have to result in T = float.
And with testFunction("") the compiler would have multiple choices for T.

With the original TestAlias it's more straight-forward, but the compiler would
still have to analyze TestAlias's implementation. That's probably not feasible
(maybe impossible) in the general case.

Maybe simple cases could be supported. But that would be an enhancement
request, I think. And then there's always the question of where to draw the
line, and if it's not better to minimize surprises by just rejecting any such
code.

--

[Issue 16487] New: Add function to obtain the available disk space

[via Digitalmars-d-bugs]

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

  Issue ID: 16487
   Summary: Add function to obtain the available disk space
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jbc.enge...@gmail.com

Would be nice to have a function that returns the available disk space on a
given path (file, directory, server share).

Something like this:
```
// Returns ulong.max when the available disk space could not be determined.
ulong getAvailableDiskSpace(string path)
{
import std.string: toStringz;
version (WINDOWS)
{
import core.sys.windows.winbase;

ULARGE_INTEGER freeBytesAvailable;
auto pathCstr = (driveName(path) ~ dirSeparator).toStringz();
bool success = GetDiskFreeSpaceExW(path, , null,
null);
return success ? free_bytes.QuadPart : ulong.max;
}
else
{
import core.sys.posix.sys.statvfs;

statvfs_t stats;
int err = statvfs(path.toStringz(), );
return !err ? stats.f_bavail * stats.f_frsize : ulong.max;
}
}
```

--

[Issue 11331] Inefficient initialization of struct with members = void

[via Digitalmars-d-bugs]

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

gyroh...@gmail.com changed:

   What|Removed |Added

 CC||gyroh...@gmail.com

--- Comment #5 from gyroh...@gmail.com ---
Is anything being worked on to change this?

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Windows |All

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

--- Comment #8 from Sky Thirteenth  ---
(In reply to b2.temp from comment #7)
> (In reply to Sky Thirteenth from comment #6)
> > (In reply to b2.temp from comment #5)
> > > I confirm the misunderstanding. If you permit I would suggest you to close
> > > this one but to open a new issue using your second example. The first one
> > > really represented issue 6082. The second is perfectly clear.
> > 
> > Yes, sure.
> > But, you will create new one, or should I?
> 
> I wont, you will.

OK, thank you.

Here the new one https://issues.dlang.org/show_bug.cgi?id=16486

--

[Issue 16486] New: Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

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

  Issue ID: 16486
   Summary: Compiler see template alias like a separate type in
template function definition
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sky.13th...@gmail.com

For example, here the type:
```
struct TestType(T, size_t size)
{
T[size] data;
}
```

And, for some reason, We want to have some aliases on it:
```
alias TestAliasA= TestType;
alias TestAliasB(T) = TestType!(T, 3);
```

Then We, obviously, somehow use them:
```
void testFunctionA(T)(TestType!(T, 3) arg)
{
writeln( arg );
}

void testFunctionB(T)(TestAliasA!(T, 3) arg)
{
writeln( arg );
}

void testFunctionC(T)(TestAliasB!T arg)
{
writeln( arg );
}
```

But there is the problem with usage of `testFunctionC`.
It cause compiler error. It just simply can not recognize
that TestAliasB!T and TestType!(int, 3) is the same type, 
rather than different.

Here complete example: https://dpaste.dzfl.pl/2c8e1c350182

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

--- Comment #7 from b2.t...@gmx.com ---
(In reply to Sky Thirteenth from comment #6)
> (In reply to b2.temp from comment #5)
> > I confirm the misunderstanding. If you permit I would suggest you to close
> > this one but to open a new issue using your second example. The first one
> > really represented issue 6082. The second is perfectly clear.
> 
> Yes, sure.
> But, you will create new one, or should I?

I wont, you will.

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

--- Comment #6 from Sky Thirteenth  ---
(In reply to b2.temp from comment #5)
> I confirm the misunderstanding. If you permit I would suggest you to close
> this one but to open a new issue using your second example. The first one
> really represented issue 6082. The second is perfectly clear.

Yes, sure.
But, you will create new one, or should I?

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

--- Comment #5 from b2.t...@gmx.com ---
I confirm the misunderstanding. If you permit I would suggest you to close this
one but to open a new issue using your second example. The first one really
represented issue 6082. The second is perfectly clear.

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

Sky Thirteenth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #4 from Sky Thirteenth  ---

(In addition to Sky Thirteenth from comment #3)
> (In reply to b2.temp from comment #2)
> > This is not a bug, this is issue 6082. IFTI doesn't support this yet.
> > 
> > *** This issue has been marked as a duplicate of issue 6082 ***
> 
> Sorry, but not we have some misunderstanding.
> 
> Question is not about a constructors. It about a types.
> 
> Here is more clear example: https://dpaste.dzfl.pl/2c8e1c350182

Template aliases does not work correct while it used with template functions.
Compiler just somehow can't understand that is the same type, rather than
different.

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

--- Comment #3 from Sky Thirteenth  ---
(In reply to b2.temp from comment #2)
> This is not a bug, this is issue 6082. IFTI doesn't support this yet.
> 
> *** This issue has been marked as a duplicate of issue 6082 ***

Sorry, but not we have some misunderstanding.

Question is not about a constructors. It about a types.

Here is more clear example: https://dpaste.dzfl.pl/2c8e1c350182

--

[Issue 6082] Constructors of templated types should be callable via IFTI

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||sky.13th...@gmail.com

--- Comment #3 from b2.t...@gmx.com ---
*** Issue 16465 has been marked as a duplicate of this issue. ***

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from b2.t...@gmx.com ---
This is not a bug, this is issue 6082. IFTI doesn't support this yet.

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

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #1 from b2.t...@gmx.com ---
1. I don't see the first function working.
(https://dpaste.dzfl.pl/2b462faf70b0). WHen you try to instantiate both gives
the same error.

2. If you don't do partial instantiation then your alias can be declared more
simply as 'alias TestAlias = TestType;'

3. The real problem you encounter here is that TestType template argument
cannot be deduced from the value passed to the constructor:

struct TestType(T)
{
T data;
}

void main()
{
auto a = TestType(0); // same error
}

This is exactly what happens when you call TestFunctionA.
For example you can replace the declaration by:

void testFunctionB(T)(T arg)
and if you call

testFunction(TestType(0));

you get exactly the same error.

--

[Issue 16465] Template alias does not get unwrapped in templated functions

[via Digitalmars-d-bugs]

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

Sky Thirteenth  changed:

   What|Removed |Added

   Severity|normal  |major

--