Re: C#7 features

[Simen Kjaeraas via Digitalmars-d-announce]

On Monday, 9 May 2016 at 00:44:09 UTC, Peter Häggman wrote:


Their tuples seem to be a complete DIY:

https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx

I wouldn't be surpised to see in the implementation an array of 
variant or something like that, explaining why it's limited to 
octuples [1]. Sharp tuples look weak compared to D tuple-ish 
things: Tuple, TList, AliasSeq, variadics, ...


[1] Also I think that the param-"variadicity" is simply 
emulated via a set of overloaded constructor, explaining why 
they stop at 8.


C#'s tuples are actually 8 different templated classes - one for 
each arity. There's a lot of duplicated code to make that work. 
Wait, it's actually 9 classes - in addition to Tuple through 
Tuple there's the humble Tuple - a non-generic class 
that cannot be instantiated and only exists to be a namespace for 
the Tuple.Create function. The example code on gooroo seems to 
have eaten the template arguments for the constructor example - 
to instantiate a tuple you use one of these syntaxen:


  var t1 = new Tuple(1, "foo");
  var t2 = Tuple.Create(2, "bar");

The 'templates' in C# are (much) more limited than old C++ 
templates, and have nothing on D's templates. That's not 
necessarily a bad thing, though - the language is different and 
fills a different niche. It does mean some things that are very 
elegant in D end up very inelegant in C#, though.

Re: Units of Measurement Library: units-d

[Simen Kjaeraas via Digitalmars-d-announce]

On Saturday, 2 April 2016 at 01:19:45 UTC, Meta wrote:

What is needed is Lisp's gensym construct.


That's basically what I said, no? :p

One problem of lisp's gensym (if we were to use it in D) is that 
it's simply a monotonically increasing number with a global 
prefix. It's perfect for the language it's in, and all but 
useless in D.


For this very reason, I have made a stab at implementing 
__GENSYM__ in D. It follows basically the ideas I outlined above, 
and spits out a string on the form MANGLE_#, with # being a 
counter for the given mangled name:


module bar;
struct Ham(string gensym = __GENSYM__) {
pragma(msg, gensym);
}
struct Eggs(string gensym = __GENSYM__) {
pragma(msg, gensym);
}

// ===

module foo;
import bar;

pragma(msg, __GENSYM__); // 3foo_1

void main() {
pragma(msg, __GENSYM__); // _Dmain_1
Ham!() a; // _Dmain_3bar_1
Ham!() b; // _Dmain_3bar_2
assert(!is(typeof(a) == typeof(b)));
Eggs!() c; // _Dmain_3bar_3
S2!() d; // _Dmain_3foo_1
}

struct Qux {
pragma(msg, __GENSYM__); // 3foo3Qux_1
void baz() {
pragma(msg, __GENSYM__); // _D3foo3Qux3bazMFZv_1
Ham!() a; // _D3foo3Qux3bazMFZv_3bar_1
}
}

struct S2(string gensym = __GENSYM__) {
pragma(msg, gensym);
}

Should I file an enhancement for this?

--
  Simen

Re: Units of Measurement Library: units-d

[Simen Kjaeraas via Digitalmars-d-announce]

On Friday, 1 April 2016 at 21:46:35 UTC, ag0aep6g wrote:

On 01.04.2016 22:59, Simen Kjaeraas wrote:
The usual way to fix it would be to include __FILE__ and 
__LINE__ in the

template arguments:


Right, no mixin this way. I wouldn't call this "truly nice", 
though.


It depends on code formatting to work. Put everything on one 
line and it breaks. Significant whitespace is a pain when 
generating code. Though this is not nearly as bad as 
significant indentation, of course.


__FILE__ also kind of breaks separate compilation. All object 
files have to be compiled from the same directory. Otherwise 
__FILE__ will be different.


__LINE__ has a similar (maybe even more obscure) issue. Add or 
remove a newline before compiling dependent modules and things 
break. Usually, one recompiles all dependents when a dependency 
changes, but a significant newline, really?


I kinda agree. And looking at https://dlang.org/spec/traits.html, 
I see there's __MODULE__, which would probably be a better choice 
than __FILE__.


As for __LINE__, what we'd want is basically something like 
__CONTEXT__, which doesn't exist, but might be the .mangleof of 
the surrounding scope:


struct S(string ctx = __CONTEXT__) {
pragma(msg, ctx);
}

S!() a; // "3foo"

void bar() {
S!() b; // "_D3foo3barFZv"
}

struct S2 {
S!() c; // "S3foo2S2"
void baz() {
S!() d; // "_D3foo2S23bazMFZv"
}
}

That'd remove the problem of significant whitespace. In fact, 
it'd also eliminate the need for __MODULE__ in this case.


Still though, that's not enough if we want this to work:

void foo() {
alias a = Foo!(); alias b = Foo!();
assert(!isSame!(a, b));
}

We could also add __COLUMN__, which would be the horizontal index 
of the instantiation's beginning:


foo(3, Bar!3.baz);
// ^Here. Position 11.

Next problem:

void main() {
pragma(msg, __LINE__);
mixin("pragma(msg, __LINE__);\npragma(msg, __LINE__);");
pragma(msg, __LINE__);
}

That prints '4' twice - once for the actual line 4, the other for 
the second line of the mixin. However, __FILE__ is different, so 
I guess __CONTEXT__ could also be.


--
  Simen

Re: Units of Measurement Library: units-d

[Simen Kjaeraas via Digitalmars-d-announce]

On Friday, 1 April 2016 at 19:03:03 UTC, ag0aep6g wrote:
I dislike that the type depends only on the given name. This 
effectively means that the names are in a global namespace.

[snip]
I can't think of a truly nice way to accomplish this, though. 
As far as I see, it needs a mixin of some kind.


The usual way to fix it would be to include __FILE__ and __LINE__ 
in the template arguments:


// In units/package.d:
struct BaseUnit(string name, string symbol = null, string file = 
__FILE__, size_t line = __LINE__)

{
   // ...
}

// in foo.d:
import experimental.units;
struct A
{
 // Actual type is BaseUnit!("Ampere", "A", "foo", 5):
alias BaseUnit!("Ampere", "A") Ampere;
enum ampere = Ampere.init;
}

struct B
{
 // Actual type is BaseUnit!("Ampere", "A", "foo", 12):
alias BaseUnit!("Ampere", "A") Ampere;
enum ampere = Ampere.init;
}

void main() {
assert(!is(B.Ampere == A.Ampere));
}

--
  Simen

Re: [Blog post] Why and when you should use SoA

[Simen Kjaeraas via Digitalmars-d-announce]

On Friday, 25 March 2016 at 01:07:16 UTC, maik klein wrote:

Link to the blog post: https://maikklein.github.io/post/soa-d/
Link to the reddit discussion: 
https://www.reddit.com/r/programming/comments/4buivf/why_and_when_you_should_use_soa/


Neat. I've actually thought about writing exactly this kind of 
template for the fun of it. Thank you for showing how it'd work.


Btw, your use of Tuple!ArrayTypes for the 'containers' field 
strikes me as unnecessary, as ArrayTypes on its own would cover 
all your use cases.


--
  Simen