[Issue 8762] New: instanceOf trait for static conditionals
http://d.puremagic.com/issues/show_bug.cgi?id=8762
Summary: instanceOf trait for static conditionals
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-10-05 02:23:10 PDT ---
As discussed here:
http://forum.dlang.org/thread/ssqgyxzggmzugbfbb...@forum.dlang.org
The idea would be a trait instanceOf!T that returns a reference to a T. The
advantage of this approach is that it allows extracting an instance out of T,
without ever worrying about how or where said instance came from.
This is particularly important because some types don't have T.init, and
immutables don't have T t = void. The intersection of both these groups is {0}
...
Example:
//
template isAssignable(T, U)
{
enum bool isAssignable =
is(typeof(instanceOf!T = instanceOf!U));
}
//
The signature (as improved on by Simen Kjaeraas) would be:
//
@property ref T instanceOf( T )( );
//
But remain un-implemented.
This would ensure it is not actually usable during run-time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8763] New: struct initialization with empty variadic arguments tries to call constructor
http://d.puremagic.com/issues/show_bug.cgi?id=8763
Summary: struct initialization with empty variadic arguments
tries to call constructor
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-10-05 03:17:07 PDT ---
//
struct S
{
this(int);
}
void foo(T, Args...)(Args args)
{
T t = T(args); Error: constructor main.S.this (int) is not callable using
argument types ()
}
void main()
{
S t = S(); //OK, initialize to S.init
foo!S();
}
//
Basically, the compiler gets confused about T(args), and tries to call S's
constructor this(int).
Proper behavior would be to call T() and initialize to T.init
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8705] std.conv.to bug, from documentation
http://d.puremagic.com/issues/show_bug.cgi?id=8705 --- Comment #2 from github-bugzi...@puremagic.com 2012-10-05 04:39:14 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/8f3e74b7448371bc89a5229ca4796bf2b53b8f4d Fix for issue 8705 (from doc) (again) https://github.com/D-Programming-Language/phobos/commit/2aceab7064cf7e97de6ddf62e78881a5ad25aebb Merge pull request #836 from monarchdodra/bug8705 Fix for issue 8705 (from doc) (again) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8764] New: chunks.transposed causes infinite ranges.
http://d.puremagic.com/issues/show_bug.cgi?id=8764
Summary: chunks.transposed causes infinite ranges.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas simen.kja...@gmail.com 2012-10-05 06:55:12
PDT ---
import std.range;
import std.stdio : writeln;
void main( ) {
ulong[1] t0;
auto t1 = t0[].chunks(1).transposed;
writeln(t1);
}
The above code spews out a never-ending string of [0]s.
Add a very simple .array before .transposed, and things work perfectly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5212] Safer typesafe variadics
http://d.puremagic.com/issues/show_bug.cgi?id=5212 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #8 from hst...@quickfur.ath.cx 2012-10-05 08:09:30 PDT --- At the very least, the compiler should be improved to perform proper data flow analysis for these kinds of cases, and detect the escaping reference to the on-stack array. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5212] Safer typesafe variadics
http://d.puremagic.com/issues/show_bug.cgi?id=5212
--- Comment #9 from hst...@quickfur.ath.cx 2012-10-05 08:17:58 PDT ---
P.S. This bug still happens in latest git (dmd 2.061). Here's another test
case:
import std.conv;
import std.stdio;
class C {
real[] val;
this(real[] v...) {
val = v;
}
override string toString() {
return to!string(val);
}
}
C f() {
return new C(1.0);
}
void main() {
auto e = f();
writeln(e);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7603] Default initializer for ref/out must be an lvalue
http://d.puremagic.com/issues/show_bug.cgi?id=7603
--- Comment #6 from Maxim Fomin ma...@maxim-fomin.ru 2012-10-05 09:41:09 PDT
---
(In reply to comment #5)
(In reply to comment #4)
Why wouldn't this fail? Default arguments are used if no argument is given.
Sine you provide arguments and functions don't modify them, arguments are
not
changed. The only modification happens due to parameter storage class out.
void test1(ref int val = 10) {}
void test2(out int val = 20) {}
void main() {
int x = 5;
test1(x);
assert(x == 5);
test2(x);
assert(x == 0);
}
Passes both assertions as it should.
Ignoring what bear's confusion here, the function declaration is invalid. Call
test1() alone:
void test1(ref int val = 10) { }
void main()
{
test1(); // Error: constant 10 is not an lvalue
}
It makes no sense adding default arguments if they'll never compile, so this
needs to be a CT error when the function is parsed and not when the function
is
called.
Agree here, but I was talking about that it is logically that those asserts
should fail, rather than about accepting non-lvalue default arguments.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8683] bad type resolution for template property functions
http://d.puremagic.com/issues/show_bug.cgi?id=8683 --- Comment #3 from Maxim Fomin ma...@maxim-fomin.ru 2012-10-05 10:37:03 PDT --- This code demonstrates the issue http://dpaste.dzfl.pl/9f2cc42f -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8683] bad type resolution for template property functions
http://d.puremagic.com/issues/show_bug.cgi?id=8683 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #2 from Maxim Fomin ma...@maxim-fomin.ru 2012-10-05 10:35:47 PDT --- (In reply to comment #0) skip It may or may not be a bug depending on what spec says and it says little about it. Dlang.org template page says that semantic analysis is done after template instantiation and in your case it is not instantiated. On the one hand, it is obvious that return type does not vary and is always int. On the other hand, dmd is not obligated to do so until full template instantiation. TDPL p.139-140 says that D uses heterogeneous translation which means that int Foo()() is not a compiled function like int Goo(). At p.236 it additionally says that Foo()() is not a type, it's a means to create a type. This means that asking a typeof from something that is not a type is problematic. The key point here is whether typeof(Foo) should instantiate type or not for templates like Foo. If it should instantiate, then it should correctly parse return type. If not (and it seems that typeof of templates which cannot be easily instantiated as Foo), than typeof should return some invalid type (like void) or just issue error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8737] Associative Array (AA) KeyType is not Unqual-able
http://d.puremagic.com/issues/show_bug.cgi?id=8737 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from monarchdo...@gmail.com 2012-10-05 15:39:43 PDT --- Invalid per https://github.com/D-Programming-Language/phobos/pull/822 . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7752] Static array .init is actually .init of the array element type, not the array.
http://d.puremagic.com/issues/show_bug.cgi?id=7752 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from monarchdo...@gmail.com 2012-10-05 15:43:31 PDT --- Well, this was either invalid, or fixed, but it works now anyways. Closing as resilved/worksforme -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8765] New: assert should print the source code for the condition when no message argument present
http://d.puremagic.com/issues/show_bug.cgi?id=8765 Summary: assert should print the source code for the condition when no message argument present Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: v...@markovic.io --- Comment #0 from Val Markovic v...@markovic.io 2012-10-05 19:59:52 PDT --- I'd love to see the following: assert(5 == 4); print out the actual source code of the condition on failure, that is core.exception.AssertError@foo.d(123): 5 == 4. This should happen when there is no user-defined message (and maybe _in addition to_ the provided message). Currently I just get unittest failure instead of the condition source, which is useless. This would make it far, far easier to track down which assert failed without having to actually go look at the line number in the file. Also, this is what most unit-testing libraries for other languages do already, like for example GoogleTest for C++ etc. Since assert() is not a function but an expression in the language, this should not be impossible to implement, should it? GoogleTest does it with macros, but (thank God) we don't have those in D. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8766] New: unexpected compile-time error when switching a struct definition to a class
http://d.puremagic.com/issues/show_bug.cgi?id=8766
Summary: unexpected compile-time error when switching a struct
definition to a class
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: blo...@hotmail.com
--- Comment #0 from Christopher Crouzet blo...@hotmail.com 2012-10-05
20:01:04 PDT ---
Please consider the code below:
// --
enum Storage : int
{
dynamic = 0
}
enum StorageOrder : int
{
columnMajor = 0,
rowMajor = 1
}
alias StorageOrder.columnMajor defaultStorageOrder;
class Array( T_scalar, T_args ... )
{
alias ArrayTraits!( T_scalar, T_args ) traits;
}
struct ArrayTraits( T_scalar, T_args ... )
{
static if ( hasFlag( Flags.storageOrder ) == true )
alias T_args[0 .. $ - 1] shapeTuple;
else
alias T_args shapeTuple;
static immutable StorageOrder storageOrder = hasFlag( Flags.storageOrder ) ?
T_args[$ - 1] : defaultStorageOrder;
static int getFlags()
{
int flags = 0;
if ( is( typeof( T_args[$ - 1] ) == StorageOrder ) )
flags |= Flags.storageOrder;
return flags;
}
static bool hasFlag( Flags flag )
{
return (getFlags() flag) != 0;
}
enum Flags : int
{
dynamic = 1 0,
storageOrder = 1 1
}
}
void main()
{
auto array1d = new Array!( float, 3 );
}
// --
It all compiles fine as it is and produce the expected results.
Now, if you declare ArrayTraits as a class rather than a struct, then the
compilation fails saying that the variable 'flag' cannot be read at compile
time. I might be wrong, but when comparing the specs of classes and structs
from the doc below, I don't see anything that would explain this error
happenning only in one case but not the other?
http://dlang.org/struct.html
Also, if you keep it declared as a class but this time define the hasFlag()
arguments at conpile-time, such as
static bool hasFlag( Flags flag )()
and adequately replace the calls to this method, then it compiles fine. I'm
getting confused here and am not sure anymore if how I initially declared it is
valid or not?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8767] New: expression of type bool() does not have a boolean value?
http://d.puremagic.com/issues/show_bug.cgi?id=8767
Summary: expression of type bool() does not have a boolean
value?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: blo...@hotmail.com
--- Comment #0 from Christopher Crouzet blo...@hotmail.com 2012-10-05
20:13:57 PDT ---
Please consider the code below:
// --
enum Storage : int
{
dynamic = 0
}
enum StorageOrder : int
{
columnMajor = 0,
rowMajor = 1
}
alias StorageOrder.columnMajor defaultStorageOrder;
class Array( T_scalar, T_args ... )
{
alias ArrayTraits!( T_scalar, T_args ) traits;
}
class ArrayTraits( T_scalar, T_args ... )
{
static if ( hasFlag!( Flags.storageOrder ) )
alias T_args[0 .. $ - 1] shapeTuple;
else
alias T_args shapeTuple;
static immutable StorageOrder storageOrder = hasFlag!( Flags.storageOrder ) ?
T_args[$ - 1] : defaultStorageOrder;
static int getFlags()
{
int flags = 0;
if ( is( typeof( T_args[$ - 1] ) == StorageOrder ) )
flags |= Flags.storageOrder;
return flags;
}
static bool hasFlag( Flags flag )()
{
return (getFlags() flag) != 0;
}
enum Flags : int
{
dynamic = 1 0,
storageOrder = 1 1
}
}
void main()
{
auto array1d = new Array!( float, 3 );
}
// --
It triggers a compilation error, which is:
/home/c189/c597.d(23): Error: expression hasFlag!(cast(Flags)2) of type bool()
does not have a boolean value
It can be fixed in the code by changing the erroring line to:
static if ( hasFlag!( Flags.storageOrder ) == true )
but I don't really understand why the comparison to true must be explicitely
written since the hasFlag() method returns a bool value?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8753] Too aggressive expansion for variables which have void initializer
http://d.puremagic.com/issues/show_bug.cgi?id=8753 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-10-05 22:00:29 PDT --- From the discussion in github, I've agreed that this is an invalid issue. By Don Clugston, I am sorry, I'm completely unconvinced by this. If you write: immutable int ix = void, there is no way, without breaking the type system, that ix could ever be given a value. Such code is simply wrong. Now we could change the meaning of = void to mean, set in a constructor. In that case, immutable int ix = void; and immutable int ix; are the same. Then no constant folding would ever be performed on something with a void initializer. I think that's a reasonable language change. But even in this case, the test code should not compile (it's neither in module scope, where there could be a static this, nor in an aggregate where there could be a constructor). The situation in bug 3449 is an entirely different issue. Then, const/immutable local variables which initialized with void is meaningless. Such compiler's behavior might not be so bad. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8762] instanceOf trait for static conditionals
http://d.puremagic.com/issues/show_bug.cgi?id=8762 --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-10-05 22:06:12 PDT --- In std.traits module, similar utility already exists (but today, it is private template). And recently I've posted a pull request which updates it. https://github.com/D-Programming-Language/phobos/pull/842 https://github.com/D-Programming-Language/phobos/pull/842/files#L1R140 The name `defaultInit` comes from `default initializer` for T (, and the name is used in the dmd implementation). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8747] isAssignable!(int, const(int)) is false
http://d.puremagic.com/issues/show_bug.cgi?id=8747 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8705] std.conv.to bug, from documentation
http://d.puremagic.com/issues/show_bug.cgi?id=8705 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Version|unspecified |D2 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-10-05 22:51:02 PDT --- More fix: https://github.com/D-Programming-Language/phobos/pull/844 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
