Re: sumtype 1.0.0

[aliak via Digitalmars-d-announce]

On Sunday, 15 November 2020 at 20:05:16 UTC, Paul Backus wrote:
SumType is a generic discriminated union type for modern D. It 
is designed to

be an improved alternative to `std.variant.Algebraic`.

[...]


Alright!!  A 1.0.0 release! Awesome work here!

Re: Article: the feature that makes D my favorite programming language

[Aliak via Digitalmars-d-announce]

On Saturday, 25 July 2020 at 16:22:52 UTC, H. S. Teoh wrote:
On Sat, Jul 25, 2020 at 01:28:34PM +, Adam D. Ruppe via 
Digitalmars-d-announce wrote:

On Saturday, 25 July 2020 at 11:12:16 UTC, aberba wrote:
> Oop! Chaining the writeln too could have increased the wow 
> factor. I didn't see that.


oh I hate it when people do that though, it just looks off to 
me at that point.


Me too.  It gives me the same creepie-feelies as when people 
write

writeln(x) as:

writeln = x;

Actually, D's lax syntax surrounding the = operator gives rise 
to the following reverse-UFCS nastiness:


	// Cover your eyes (unless you're reverse-Polish :-P)! and 
don't

// do this at home, it will corrupt your sense of good coding
// style!
import std;
void main() {
writeln = filter!(x => x % 3 == 1)
= map!(x => x*2)
= [ 1, 2, 3, 4, 5, 6 ];
}

// Output: [4, 10]


T


Oh my god ... it’s like haskells $ 樂

Why is this allowed?

I mean, ok, it was probably done to allow property syntax. But 
how did this end up being applied to every function?


Can this be fixed?

Re: DIP1028 - Rationale for accepting as is

[Aliak via Digitalmars-d-announce]

On Wednesday, 27 May 2020 at 02:42:24 UTC, Walter Bright wrote:

On 5/24/2020 6:04 PM, Timon Gehr wrote:
Implicit greenwashing by the compiler is a nuisance that makes 
it harder to do the job correctly and easier to do the wrong 
thing.


You and I are just going to disagree about that.


Unfortunately science and research Doesn't agree with you. 
https://en.m.wikipedia.org/wiki/Default_effect

Re: DIP1028 - Rationale for accepting as is

[aliak via Digitalmars-d-announce]

On Sunday, 24 May 2020 at 11:30:53 UTC, Johannes Loher wrote:

On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote:

On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to 
have 2 different defaults.


Is that any more or less weirder than having functions 
inferred with different attributes based on context?


What exactly are you referring to?


Attribute inference by D, specifically template functions. The 
attributes are inferred based on context (I don't know the exact 
algorithm). So a function f(T)(T) when called can maybe be pure, 
maybe safe, maybe not?

Re: DIP1028 - Rationale for accepting as is

[aliak via Digitalmars-d-announce]

On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to 
have 2 different defaults.


Is that any more or less weirder than having functions inferred 
with different attributes based on context?

Re: DIP1028 - Rationale for accepting as is

[aliak via Digitalmars-d-announce]

First, thank you for the explanation! I have a few observations 
though, mainly that the exception analogy feels like more an 
argument against the DIP than for it. And I also have an 
alternative proposal that might be considered?


On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
This, of course, was incredibly tedious and annoying. So what 
happened?


1. Functions would just do a try-catch(Throwable) and ignore 
the exceptions.

Oops.

2. The Exception Specifications became simply `throws 
Throwable`. Oops.


This is what happens in swift these days:

func g() /*throws*/ {
  do {
try f()
  } catch {}
}

But, it's very rare. And passing something like that in code 
review is very difficult and, almost always, the reviewer will 
ask for comments so other people will know why the laziness (if 
it even really was laziness, sometimes it's the right thing to 
do).


Of course the one big difference between exception specifications 
and @safe is the implied importance; @safe is compiler-enforced 
and has the user's trust, exception specifications are human 
guess work of what are the important exceptions and how varied 
they need to be - it's API design - very hard to get right.


The exception specification becoming "throws Exception", while 
highlights the failure of exception specifications, does so with 
a non-dangerous resolution. I.e. you still need to mark your 
function as throwing, and you still need to at least "try" to 
catch the exception. Even a forced "catch(Exception)" is better 
than nothing and shows where problems can be and encourages 
scrutiny.



How does this relate to safe by default?


That people will use the most convenient solution to get their 
work to compile if the juice is not worth the squeeze?




1. Go through...

2. Annotate...safe by default to be lost.

3. Wrap the call...

4. Edit clibrary.d and make the first line:

@safe:


5. Edit clibrary.d and make the first line @trusted: ?

Which brings me to the proposal of making @safe illegal on 
function prototypes. Reason being that @safe stays compiler 
checked. @trusted maintains it's path and value in hunting down 
memory corruption. extern(Anything) functions cannot lie anymore 
about being compiler-checked.




I submit that, just like with Java, Option 4 is what people 
will reach for,
nearly every time. I've had some private conversations where 
people admitted
this was what they'd do. People who knew it was wrong to do 
that.


If it's @safe by default, and then someone chooses to annotate 
it with @system


Which is the rare case in this scenario right? And 1) there's no 
way to tell if someone made an effort in the case where none are 
marked @system. 2) this is also only for the case of C library 
bindings (reason being that most of my code, and also others' 
code I've seen, has extern(C) functions splattered around various 
D files and not in a dedicated clibrary.d file - is this just me?)


here and there, I'd feel a lot more confident about the 
accuracy of the code
annotations than if it just had @safe: at the top. At least 
they tried.


What is actually accomplished with this amendment if it was 
implemented?


1. Adds a funky, special case rule. It's better to have simple, 
easily
understood rules than ones with special cases offering little 
improvement.


2. Existing, working code breaks.

3. The most likely code fixes are to just make it compile, 
absolutely
nothing safety-wise is improved. The added annotations will be 
a fraud.


D should not encourage "greenwashing" practices like the Java
exception specification engendered. The compiler cannot vet the 
accuracy
of bodyless C functions, and we'll just have to live with that. 
The proposed

amendment does not fix that.

And so, I did not incorporate the proposed amendment to the 
Safe by Default

DIP.


I think there's a failure to understand why explicit greenwashing 
via a deliberate (possibly code reviewed) addition of @safe: at 
the top is worse than a global implicit greenwashing by the 
compiler, ignoring the rare "feel-good-but-can't-be-sure" 
scenario above where some functions are marked as @system, and 
especially given the premise that programmers are lazy.


Also ... error on @safe prototypes?

Re: DLS deprecation

[aliak via Digitalmars-d-announce]

On Tuesday, 7 April 2020 at 22:20:40 UTC, Laurent Tréguier wrote:

On Tuesday, 7 April 2020 at 20:03:21 UTC, Aliak wrote:
Is what you’re working on shareable information (just out of 
curiosity)?


It's shareable (it's on Github just like DLS); it's a mobile 
app, the Android version is in Kotlin, and the iOS version in 
Swift. I think it's hard to beat native languages for these 
platforms, as they both have tailored APIs and development 
environments (and they are backed by giant companies putting 
lots of resources into them)


Yeah, no doubt, it's always that last 10-20 percent of the way 
you have to go with the non-native languages on those platforms 
that gets you. The downside is the manpower required to maintain 
two platforms.


I've been meaning to give flutter a try though... it seems to be 
catching steam. Only problem is google is "known" for just 
dropping things. But who knows, let's see.


And WildFyre looks very interesting! Good luck with your future 
endeavours!

Re: DLS deprecation

[Aliak via Digitalmars-d-announce]

On Tuesday, 7 April 2020 at 19:12:49 UTC, Laurent Tréguier wrote:
I started working on this project to make it more comfortable 
to write D back in 2017, published a VSCode extension a couple 
months later, and continued working on it throughout 2018. In 
2019 however, I slowed down, and eventually, stopped working on 
it.


It was fun, and kept me well occupied for quite some time; but 
I have been working on something else since April of last year, 
and since I don't have any use for D in it, I am not taking 
time to do anything with DLS.


So today, I am deprecating DLS, along with its editor 
extensions. If anyone was using them, be advised that they will 
not have any update or support from now on.


Webfreak is still working on code-d/serve-d from what I gather, 
so hopefully, the handful of people who could be using DLS on 
VSCode can use it instead.


No

DLS was so fast and smooth :(

But ah well. Thanks for all the work and for the heads up!

Is what you’re working on shareable information (just out of 
curiosity)?


Cheers and good luck with the other stuff!

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

On Saturday, 29 February 2020 at 14:41:16 UTC, Steven 
Schveighoffer wrote:

On 2/28/20 7:57 PM, aliak wrote:


I actually didn't realize it was a video, thought it was just 
an article! - But anyway, it was just to point out that swift 
lowers to specialized types when it comes to interpolation 
(which is what you and adam are trying to get through). And 
therefor you can detect interpolations being given to you and 
deal with them the way you want and you can do a lot when you 
know you're getting an interpolation. You can create types like


let example: SQLStatment = "select * from blah where a=\(a), 
b=\(b) ... "


I didn't get to this part of the video, but that is indeed 
pretty cool. I'm assuming that this generates placeholders for 
the SQL statement and attaches a and b as parameters?


I'm not sure if it's in the video (I haven't seen the video). But 
it was just an example, implementations would vary I'd assume. 
Here's one from a quick search for e.g.: 
https://github.com/groue/GRDB.swift/blob/4c8574aa4c08ff715ce0e63b38502ac1e8529069/GRDB/Core/SQLInterpolation.swift




However, D cannot do something like this exactly, because 
expressions define the tuple, not how they are used.


Yep, and similarly expressions define the interpolation pattern 
in swift, not how they are used as well. So the tuple thing is 
also pretty sweet! I'd imaging you'd be able to do something like:


auto sql = SQLStatment(i"select * from blah where a=$a, b=$b");

where

struct SQLStatement {
  string formatted;
  // What template magic is needed here? This is where I get a 
little worried.
  this(S : _interpolated_object!Specs, Specs, Args...)(S s, Args 
args) {

// build formatted...?
  }
  alias formatter this;
}



But this is possible (with the proposed DIP or ours):

alias sql = "select * from blah where a=$a, b=$b"; // aliased 
to the tuple


connection.query(sql);
a = 5;
connection.query(sql); // another query with `a` set to 5 now.


Yeah, and that's pretty sweet too!



Swift can do some pretty cool things due to the type resolver, 
but it comes at a cost (some expressions that are trivial in D 
make the compiler complain about them taking too long to 
resolve).


Yeah, swift ha a few problems with its type solver during 
semantic I think.


let a: Double = -(1 + 2) + -(3 + 4) + -(5)

Will fail to compile on my machine, and you need to break it up.

But, on the other hand, swift's constraint solver avoids 
backwards situations like:


void f(bool) { "bool".writeln; }
void f(int) { "int".writeln; }
enum A { one }
void main() {
f(0);
f(A.one);
}

And:

void main() {
struct B {
B opBinary(string op : "+")(int b) { return this; }
}
static if (is(typeof(B.init + size_t.init))) {
size_t x = 1;
B b1, b2;
b1 = b2 + x; // fails here
}
}




I also didn't realize the takeaway would be that swift does 
appending - which by the way, is not completely accurate. And 
it does not generate temporaries (unless you mean passing in 
parameters? There's no way around that if you want to end up 
with a string based on runtime values - it'll have to be 
processed in to a string somewhere).


For example, the part where they change the date formatting, 
they use a date formatter to generate a string for the date, 
which then is appended to the string interpolation.


Yes, you need to allocate a string. But you should only 
allocate one.


Generating temporaries is not a constraint that the interpolation 
system puts on you.




You can also get an interpolated string directly in to "print 
processing" if you wanted to: 
https://swift.godbolt.org/z/muAzgm


Hm... I'm not too impressed with this when compared to 
writefln(i"hello $("hello"), $x"); which works without such 
extra mechanics or strange call syntax.


Indeed.

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

On Friday, 28 February 2020 at 19:16:08 UTC, Steven Schveighoffer 
wrote:

On 2/28/20 5:17 AM, Jacob Carlborg wrote:
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright 
wrote:


I don't know Swift, but this looks like the "generate strings 
and concatenate them" approach.


No, it basically lowers to bunch of method calls. Here's an 
example of how it could look like with D syntax:


auto a = 3;
auto b = i"foo $a bar";

Could be lowered to:

auto _temp = StringInterpolation(8 /* literal capacity */, 1 
/* interpolation count */);

_temp.appendLiteral("foo ");
_temp.appendInterpolation(a);
_temp.appendLiteral(" bar");
auto b = _temp.toString();


I think Walter's point is that swift is still appending strings 
and then returning that. This requires allocations, and is not 
as preferable as directly processing the data. Not only that, 
but it's generating temporary strings just to add them to the 
larger thing that will be printed (I'm assuming this is not 
just a big string but an array/list, due to the beginning of 
the video and s1+s2+s3+s4).


I'd much prefer for example, printing using DIP1027 than 
constructing a string (even if the memory is reasonably fast, 
like malloc) just to throw it away.


I watched a lot of that video, it didn't impress me much. I use 
swift interpolation strings quite a bit, and they are useful. 
But I think D's will be much more performant and more 
straightforward for hooking (if they ever get in).


-Steve


I actually didn't realize it was a video, thought it was just an 
article! - But anyway, it was just to point out that swift lowers 
to specialized types when it comes to interpolation (which is 
what you and adam are trying to get through). And therefor you 
can detect interpolations being given to you and deal with them 
the way you want and you can do a lot when you know you're 
getting an interpolation. You can create types like


let example: SQLStatment = "select * from blah where a=\(a), 
b=\(b) ... "


I also didn't realize the takeaway would be that swift does 
appending - which by the way, is not completely accurate. And it 
does not generate temporaries (unless you mean passing in 
parameters? There's no way around that if you want to end up with 
a string based on runtime values - it'll have to be processed in 
to a string somewhere).


You can also get an interpolated string directly in to "print 
processing" if you wanted to: https://swift.godbolt.org/z/muAzgm


And for the record I think the tuple generation is great as well. 
I highly doubt it'll be easier to use than swift (case in point: 
no need to call idup or whatever to convert to a string, since a 
string in swift is a type that is "interpolation aware"). Hook in 
to maybe, it depends on the APIs provided to hook in to them. An 
opaque type will not be easier to hook in to and a "concrete" 
named interface (aka protocol in swift).


When it comes to printing it really doesn't matter if you 
construct a string on the stack and pass it along. You're IO 
bound anyway.


By the by: if you or anyone is interested in swift's string 
interpolation design decisions (for inspiration or whatever) then 
here's the full discussion: 
https://forums.swift.org/t/string-interpolation-revamp-design-decisions/12624


One very interesting thing of note is the way they combine named 
arguments with string interpolations.


Also another note, this tuple expansion should really not be 
called string interpolation, since it does not result in a string 
:/ It's more string expansion really.

Re: DIP 1027---String Interpolation---Format Assessment

[Aliak via Digitalmars-d-announce]

On Thursday, 27 February 2020 at 18:19:03 UTC, Adam D. Ruppe 
wrote:
On Thursday, 27 February 2020 at 17:41:12 UTC, Petar Kirov 
[ZombineDev] wrote:

[...]


Right, that actually is what my old proposal was (and I fought 
for it on the first few pages of the last thread), and this is 
very close to what C# does successfully, but I decided to leave 
it behind because:


[...]


Should this maybe be called tuple interpolation instead of string 
interpolation? It is unique to D it seems, this feature that is. 
And then it might help with the “wait why can I not assign an 
interpolated string to a string”?? And on top maybe change the 
prefix to t instead of i?

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright 
wrote:

On 2/26/2020 7:41 AM, Arine wrote:

Yah, what's unwanted about that?


1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp strings to be 
generated


Pretty sure he meant that this call:

int a;
CreateWindow(i"Title $a");

Would call CreateWindow like:

CreateWindow("Title %s", a);

Which is what is unwanted.

Btw: with the adam-steve-twist you fix everything that is 
unwanted, including enforcing explicitness when someone wants it 
to act as a string, without the danger of mistakenly calling the 
wrong overloads of functions because of switching to string 
interpolation.


And it seems to me there's precedent in typeid

i.e. typeid is an construct in D that lowers to a TypeInfo type, 
which is defined somewhere (is that object.d?) Anyway. The same 
would happen with the interpolated string.


Btw: Swift does this for string interpolation and it works very 
well -> 
https://www.hackingwithswift.com/articles/178/super-powered-string-interpolation-in-swift-5-0

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

On Tuesday, 25 February 2020 at 16:04:59 UTC, Arine wrote:
``How to distinguish a different type? Use a different type. 
No, is there another simpler way to do that instead?``


Is this really the line of thinking going on here? It seems 
Walter has these arbitrary rules he's following which led up to 
the impractical and buggy solution that was DIP1027. Rules 
aren't meant to be followed blindly.


Calm down. I didn't ask how to distinguish a type. I asked how to 
prevent a behaviour. There's a slight difference. If you 
misunderstood that then maybe I just didn't communicate that 
properly.

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

On Wednesday, 26 February 2020 at 09:45:55 UTC, Walter Bright 
wrote:

On 2/25/2020 1:36 AM, aliak wrote:
This may have already been answered in the other threads, but 
I was just wondering if anyone managed to propose a way to 
avoid this scenario with DIP1027?


void f(string s, int i = 0);
f(i"hello $a"); // silent unwanted bahviour.

?


It is lowered to:

  f("hello %s", a);

as designed. I don't know what's unwanted about it.


It's unwanted because the lowering calls a function that was not 
intended with values that were unintended. You can take this 
article: https://dlang.org/articles/hijack.html and replace it 
with that lowering behaviour, and have the exact same story.


Also unwanted because of what string interpolation means (ref 
wikipedia and all other languages).

Re: DIP 1027---String Interpolation---Format Assessment

[Aliak via Digitalmars-d-announce]

On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote:

On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:

[...]


Yes, that is the key impetus of our amendment, which I also 
wrote up on a gist weeks ago and it is now on github too! 
https://github.com/dlang/DIPs/pull/186


[...]


I should’ve been more specific  I was wondering if the same 
could be achieved without a introducing a new aggregate type!

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

On Tuesday, 25 February 2020 at 07:07:50 UTC, Walter Bright wrote:
All DIP1027 did was turn an istring into a tuple. That's it. 
The user can then do whatever they want with the tuple, 
including overloading a custom function based on the tuple 
arguments. DIP1027 did not actually do ANY formatting at all.


This may have already been answered in the other threads, but I 
was just wondering if anyone managed to propose a way to avoid 
this scenario with DIP1027?


void f(string s, int i = 0);
f(i"hello $a"); // silent unwanted bahviour.

?

Re: DIP 1027---String Interpolation---Format Assessment

[aliak via Digitalmars-d-announce]

On Monday, 24 February 2020 at 21:23:43 UTC, Adam D. Ruppe wrote:
On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright 
wrote:

and proposed a lowering to:

> i"your hex data is ${%02x}someByte"
>
> (_d_interpolated_string!("your hex data is ",
> _d_interpolated_format_spec("%02x"))(), someByte)


Do you understand that `_d_interpolated_string` and 
`_d_interpolated_format_spec` are to be defined EXCLUSIVELY 
inside druntime?


There's nothing user-defined about this.


Does that mean no betterC support if it's in druntime?

Actually, was it different with the pure tuple approach in 
DIP1027?

Re: Bolts 1.4 - added experimental signatures for D

[aliak via Digitalmars-d-announce]

On Friday, 14 February 2020 at 21:33:01 UTC, aliak wrote:

Hi,
[...]

Cheers,
- ali


Ok, you can now model an actual input range with most of it's 
caveats:


interface InputRange(T) {
@property bool empty();
@property T front();
@ignoreAttributes void popFront();
}

struct MyRange {
mixin Models!(InputRange!int);
}

source/bolts/experimental/signatures.d(341,5): Error: static 
assert:  "Type MyRange does not comply to signature 
InputRange!(int)

  Missing identifier empty of type bool.
  Missing identifier front of type int.
  Missing identifier popFront of function type void().
  source/bolts/experimental/signatures.d(8): <-- Signature 
InputRange!(int) defined here.

  source/bolts/experimental/signatures.d(15): <-- Checked here."

To fix the errors you'd need a name called empty that returns a 
bool (i.e. is a member variable or a property function). Same 
with front. And for popFront it can be a function with whichever 
attributes attached to it.


Not sure what to do with a range model that has "ref T front". 
Maybe an @ignoreRefness attribute?


Cheers

Bolts 1.4 - added experimental signatures for D

[aliak via Digitalmars-d-announce]

Hi,

I've released an experimental implementation of the concept of 
traits/signatures/protocols-ish. The basics seems to work 
decently well, with very decent error messages e.g.:


source/bolts/experimental/signature.d(111,17): Error: static 
assert:  "Type Y is missing the following members of enum X: 
["three"]
  source/bolts/experimental/signature.d(156): <-- Signature Sig 
defined here.

  source/bolts/experimental/signature.d(166): <-- Mixed in here."

Package: https://code.dlang.org/packages/bolts
Implementation PR: https://github.com/aliak00/bolts/pull/6/files

I'm not sure about a few things thought and wouldn't mind some 
feedback.


1. Malleable properties. Take input ranges for example:

struct InputRange(T) {
  bool empty() { return true; }
  // other members...
}

This works:

struct SomeRange(T) {
  mixin ModelsSignature!(InputRange!T));
  bool empty() { return true; }
  // other members...
}

But for variations such as infinite ranges, this will not work

struct SomeRange(T) {
  mixin ModelsSignature!(InputRange!T));
  enum empty = false;
  // other members...
}

The way I'm thinking of handling it right now is by using UDAs?

struct InputRange(T) {
  @onlyAssign
  bool empty;
  // other members...
}

So then the mixin template Models will check if a name has the 
UDA onlyAssign attached to it, and if so it will be more lenient 
with the SomeRange struct.


Does anyone have any other suggestions?

2. Naming. Not very happy with onlyAssign, and also 
ModelsSignature. Any bikesheds? :p


3. Having to implement functions. Like in the InputRange 
signature above, I had to implement function empty. So for that 
I'm thinking templates? Something like:


struct Signature {
  mixin Function!("f", int(int, int));
}

Or the like? And the mixin would put in a stubbed function named 
"f" that returns int.init


Opinions?

Cheers,
- ali

Re: release of code-d 0.21.0 + serve-d 0.5.1

[Aliak via Digitalmars-d-announce]

On Wednesday, 13 November 2019 at 23:17:21 UTC, WebFreak001 wrote:

hi everyone,

after a long time there is finally a new update for my Visual 
Studio Code extension "code-d"


[...]


Wow! Well done on the effort!!

Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64

[aliak via Digitalmars-d-announce]

On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote:

Hi all,
Recently there have been inquiries about support for D on 
Alpine Linux, a distribution mostly used in combination with 
Docker to create lightweight container images for microservices.


[...]


This is great! Much thanks to all for all the work towards this!

Re: When will you announce DConf 2020?

[Aliak via Digitalmars-d-announce]

On Sunday, 3 November 2019 at 00:51:38 UTC, Murilo wrote:
Hi guys. I'm eager to attend the next DConf, which is why I'm 
already planning everything about how I will travel from Brazil 
to the UK(or maybe Germany). When will you announce the place 
and date of the next DConf?


Hey! That’s awesome! The conferences are usually around May. And 
the announcements and finalization don’t really have a specific 
date but usually around Jan/feb ish (just did a quick search for 
the different years).


Cheers
Ali

Re: Átila's Vision of D's Future

[Aliak via Digitalmars-d-announce]

On Wednesday, 16 October 2019 at 12:11:23 UTC, bachmeier wrote:

On Wednesday, 16 October 2019 at 09:46:49 UTC, aliak wrote:
On Tuesday, 15 October 2019 at 20:33:32 UTC, Walter Bright 
wrote:

On 10/15/2019 6:11 AM, Mike Parker wrote:

Reddit:
https://www.reddit.com/r/d_language/comments/di7gwl/%C3%A1tilas_vision_of_ds_future/


It's also on the front page of hacker news:

https://news.ycombinator.com/news


It's better to link straight to an item on hackernews as links 
on the front page disappear very fast.


https://news.ycombinator.com/item?id=21257943

Cheers,
- Ali


You can do that once it's no longer on the front page, but if 
you do that while it's on the front page the post will be 
deleted.


So linking to this item on the front page will have it deleted?

https://news.ycombinator.com/item?id=21274511

I’d be surprised!

Re: Átila's Vision of D's Future

[Aliak via Digitalmars-d-announce]

On Wednesday, 16 October 2019 at 17:55:24 UTC, Meta wrote:

On Wednesday, 16 October 2019 at 09:46:49 UTC, aliak wrote:
It's better to link straight to an item on hackernews as links 
on the front page disappear very fast.


https://news.ycombinator.com/item?id=21257943

Cheers,
- Ali


HN has this (IMO) ridiculous policy of going to great lengths 
to prevent upvotes from people following a direct link to the 
post.


Hmm. Are you sure? I just went to that link I put up there and 
upvoted. Is this documented somewhere?

Re: Átila's Vision of D's Future

[aliak via Digitalmars-d-announce]

On Tuesday, 15 October 2019 at 20:33:32 UTC, Walter Bright wrote:

On 10/15/2019 6:11 AM, Mike Parker wrote:

Reddit:
https://www.reddit.com/r/d_language/comments/di7gwl/%C3%A1tilas_vision_of_ds_future/


It's also on the front page of hacker news:

https://news.ycombinator.com/news


It's better to link straight to an item on hackernews as links on 
the front page disappear very fast.


https://news.ycombinator.com/item?id=21257943

Cheers,
- Ali

Re: CodinGame adds support for 2 new programming languages

[Aliak via Digitalmars-d-announce]

On Thursday, 26 September 2019 at 15:58:46 UTC, Andre Pany wrote:

Hi,

Based on the voting results 
(https://www.codingame.com/forum/t/poll-what-programming-language-would-you-like-codingame-to-support-next) Codingame is currently adding 2 new programming languages, Type Script and D!


Thanks for your votes, they made it happen!

Kind regards
Andre


That is fantastic! And great job for being on top of it! :D

Re: LDC 1.17.0-beta1

[aliak via Digitalmars-d-announce]

On Saturday, 10 August 2019 at 15:51:28 UTC, kinke wrote:

Glad to announce the first beta for LDC 1.17:


Nice!



* Based on D 2.087.1+ (stable from some days ago).
  * The DMD fix wrt. 'local templates can now receive local


Are there plans to port this or is it just too unworkable as is? 
And if it is too unworkable is there anything that can be done to 
get it in?



symbols' hasn't been ported yet.
* LLVM upgraded to v8.0.1.
* Fix for v1.16.0 regression when returning void expressions.
* Don't ignore some options like `-lowmem` in response files.
* Proper Unicode support for LDC/LDMD itself on Windows.
* More fixes...

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.17.0-beta1


Please help test, and thanks to all contributors!

Re: optional 1.0.0 beta with "or/frontOr/Throw" range utilities

[aliak via Digitalmars-d-announce]

On Tuesday, 30 July 2019 at 12:58:08 UTC, Jesse Phillips wrote:

On Monday, 29 July 2019 at 22:17:20 UTC, aliak wrote:

* NotNull has been removed


Why was it removed. It seems like this would be nice to have 
for class and pointers.


I personally didn't find use for it, too much friction to use. I 
have not gotten the impression that it's useful form others 
either? If people were using it I'll gladly put it back in as a 
subpackage or something (or just make another package).

Re: optional 1.0.0 beta with "or/frontOr/Throw" range utilities

[aliak via Digitalmars-d-announce]

On Tuesday, 30 July 2019 at 04:18:28 UTC, Les De Ridder wrote:

On Monday, 29 July 2019 at 22:17:20 UTC, aliak wrote:

[...]

* dispatch() has been renamed to oc(); "optional chain"


Why not 'chain()' or 'optionalChain()'?


Only because chain is in range and optionalChain is too long 路‍♂️.

Re: optional 1.0.0 beta with "or/frontOr/Throw" range utilities

[Aliak via Digitalmars-d-announce]

On Monday, 29 July 2019 at 22:17:20 UTC, aliak wrote:

Hi




Link: https://code.dlang.org/packages/optional

optional 1.0.0 beta with "or/frontOr/Throw" range utilities

[aliak via Digitalmars-d-announce]

Hi,

After some feedback from the community [0], I'm happy to finally 
get the optional package to a 1.0.0 version. There is one 
breaking change with how pointer semantics behave, in that the 
previous version treated some!(int*)(null) as a non-empty 
optional, and some!Class(null) as an empty optional. These are 
both now treated as empty optionals.


Compilation changes include:
* orElse has been split in to "or" and "frontOr"
* dispatch() has been renamed to oc(); "optional chain"
* NotNull has been removed
* unwrap has been removed

Additions include:
* frontOrThrow: if there's no front of range then it will throw.
* or/frontOr work with any range, and Nullable!T.
* match will resolve to void if any of the handlers return void.

Added a whole bunch of "safety" checks, so CI runs with dip1000 
and dip25 enabled, and uses LLVM's address sanitizer. I still 
don't know how to deal with auto ref return values [1] so if 
anyone has any tips...


I'll remove the beta status after a few weeks if there're no 
issues.


Cheers,
- ali

[0] 
https://forum.dlang.org/thread/borsieulsqyzrfays...@forum.dlang.org

[1] https://issues.dlang.org/show_bug.cgi?id=20084

Re: Redis client hunt-redis RC1 released

[aliak via Digitalmars-d-announce]

On Tuesday, 23 July 2019 at 07:57:06 UTC, zoujiaqing wrote:

A Powerfull Redis client library for D Programming Language.

Porting from java Jedis, support redis 3.x / 4.x all features 
and 5.x

 some features.

[...]


Awesome! Huntlabs seem to really be putting in a lot of work on 
backend d-dev! Are there any websites/services you know of that 
are using the entire framework?

Re: bolts meta programming library version 1.0.0 - including the from idiom

[aliak via Digitalmars-d-announce]

On Wednesday, 17 July 2019 at 16:29:34 UTC, victoroak wrote:

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so 
decided to release it as 1.0.0 with a few enhancements chucked 
on.


[...]


Looks nice. Though, I see it has some problems that stuck me 
before. The traits isFunctionOver and isUnaryOver can't handle 
lambdas that receive arguments by ref like:


struct S {}
static assert(isFunctionOver!((ref s) => s, S));

I wish ref was part of the type in D, so we could pass ref S as 
template parameters. I could pass as string but it's error 
prone and not really elegant.


Ooh! Thanks!

Fixed and released v1.0.1

Re: bolts meta programming library version 1.0.0 - including the from idiom

[Aliak via Digitalmars-d-announce]

On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so 
decided to release it as 1.0.0 with a few enhancements chucked 
on.


[...]


Nice! I'm working on something similar but with a different 
goal.


Thanks! How’s the thing similar and what’s the goal (if you don’t 
mind me asking)?

bolts meta programming library version 1.0.0 - including the from idiom

[aliak via Digitalmars-d-announce]

I've been using a set of meta tools for a while now, so decided 
to release it as 1.0.0 with a few enhancements chucked on.


Two of the highlights are the non-eponymous "member" and "iz" 
templates, which are shown below with some code. The library also 
includes the "from" template because I tend to use that 
everywhere.


Docs: https://aliak00.github.io/bolts/bolts.html
Github: https://github.com/aliak00/bolts
Package: https://code.dlang.org/packages/bolts

Current issues include:

1) that I'm not completely sure about the behaviour of the 
copy-constructor traits - I've decided to pretend post blots 
don't exist and marked the library as requiring dmd frontend 
2.086 and above.


2) It's an ongoing battle with D to normalize parameters because 
traits return tuples, or string, or tuples of strings, or alias 
tuples, etc. And some traits take symbols, while others take 
strings, etc. One of the goals is to make this library a little 
more consistent and try and keep it that way. I will break things 
to make things consistent (is my intention).


3) Naming - e.g. why are some things in std.meta capitalized 
(i.e. Filter) and others camel-cased with a static prefix - i.e. 
staticMap? What would be the consistent thing to do? I currently 
have a staticZip in there, should it just be Zip?


Some sample code:

unittest {
import bolts;

int i;
class C { void f0() {} int f1(int) { return 0; } }
static struct S { void f0() {} int f1(int) { return 0; } 
@property void set(int) {} }


pragma(msg, from.std.allSatisfy!(iz!int.of, 3, 4, int, i)); 
// true
pragma(msg, from.std.Filter!(isNullable, int*, C, S)); // 
(int*, C)


// Member functions
pragma(msg, memberFunctionsOf!S.asStrings); // tuple("f0", 
"f1")
pragma(msg, memberFunctionsOf!C.asAliases); // tuple(f0, f1, 
toString, toHash, opCmp, opEquals, factory)


// member template
pragma(msg, member!(S, "f0").exists); // true
pragma(msg, member!(S, "f0").protection); // public
pragma(msg, member!(S, "f0").isProperty); // false
pragma(msg, member!(S, "set").propertySemantics); // 
PropertySemantics.w


// iz template
static struct OldS {
this(this) {}
}
static struct NewS {
this(ref NewS s) {}
}
pragma(msg, iz!S.triviallyCopyConstructable); // yes
pragma(msg, iz!OldS.triviallyCopyConstructable); // no 
because post-blit
pragma(msg, iz!OldS.copyConstructable); // no because post 
blit


pragma(msg, iz!NewS.copyConstructable); // yes
pragma(msg, iz!NewS.nonTriviallyCopyConstructable); // yes

// meta fun with packs and zip
{
alias a = AliasPack!(1, 2, 3);
alias b = AliasPack!(4, 5, 6);
alias c = AliasPack!(7, 8, 9);

alias d = staticZip!(a, b, c);

static assert(d.length == 3);

static assert(d.Unpack[0].equals!(1, 4, 7));
static assert(d.Unpack[1].equals!(2, 5, 8));
static assert(d.Unpack[2].equals!(3, 6, 9));

static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 
2, 5, 8, 3, 6, 9));

}
}

Cheers,
- Ali

Re: Cushion the state transition table library released

[aliak via Digitalmars-d-announce]

On Wednesday, 26 June 2019 at 15:20:45 UTC, ag0aep6g wrote:

On 26.06.19 16:01, SHOO wrote:

[...]


You've got bad `@trusted`s.

Quoting from there:

[...]


No.


[...]

[...]

[...]


Noo.


[...]

[...]

[...]

[...]

[...]

[...]

[...]


Nooo.


[...]

[...]

[...]

[...]

[...]

[...]

[...]


N.


[...]

[...]

[...]

[...]>   EventContainer   _events;
[...]

[...]

[...]

[...]

[...]

[...]

[...]

[...]


No.


I really love that you go in to the code and find things like 
this, especially when it comes to abuse of @trusted, but maybe a 
little explanation as to why would be more helpful to the OP ;)

Re: LDC 1.16.0

[aliak via Digitalmars-d-announce]

On Thursday, 20 June 2019 at 17:36:45 UTC, kinke wrote:

Glad to announce LDC 1.16:

* Based on D 2.086.1.
* Non-Windows x86: Faster `real` versions of 
std.math.{tan,expi}.

* Windows: Fix linking DLLs with MinGW-based libs.
* WebAssembly: No need for an explicit `-L--export-dynamic` 
anymore.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.16.0


Thanks to all contributors!


Cool! Thanks kinke! <3

Re: Beta 2.087.0

[aliak via Digitalmars-d-announce]

On Sunday, 16 June 2019 at 22:47:57 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.087.0 release, ♥ to 
the 66 contributors.


http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.087.0.html


As usual please report any bugs at
https://issues.dlang.org

-Martin


Wow! Very good stuff in this one!
Bug 5710, a dip 1000 phobos, and alias templates parameters match 
types!


Thanks!

Optional 0.15.0 now compatible with vibe-d, @safe, @nogc, betterC.

[aliak via Digitalmars-d-announce]

Hey,

I've recently released optional 0.15.0 [0] that includes support 
for vibe-d serialization/deserialization. So you can use it 
instead of Nullable for types that may or may not be there (I got 
bit by Nullable again so felt this had to be added [1])


Also of note is that it can be used in nogc and safe code, and is 
compatible with betterC.


Extract from readme:

* Use pattern matching, orElse
  fun.match!(
(int value) => writeln("it returns an int"),
() => writeln("did not return anything"),
  );
  fun.orElse(3); // returns some(fun()) or some(3)

* Safely call functions on classes that are null or structs that 
don't exist

  class C { int fun() { return 3; } }
  Optional!C a = null;
  a.dispatch.fun; // no crash, returns no!int

* Forwards any operator calls to the wrapped typed only if it 
exists, else just returns a none

  Optional!int a = 3;
  Optional!int b = none;
  a + a; // evaluates to some(6);
  a + b; // evaluates to no!int;

* Compatible with std.algorithm and std.range
  fun.each!(value => writeln("I got the value"));
  fun.filter!"a % 2 == 0".each!(value => writeln("got even 
value"));


Cheers,
- Ali

[0] https://code.dlang.org/packages/optional
[1] 
https://forum.dlang.org/thread/thtjhrvlgetaahcam...@forum.dlang.org

Re: LDC 1.16.0-beta1

[aliak via Digitalmars-d-announce]

On Thursday, 9 May 2019 at 21:14:02 UTC, kinke wrote:
Glad to announce the first beta for LDC 1.16; mainly just an 
upgrade to D 2.086.0.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.16.0-beta1


Please help test, and thanks to all contributors!


Yay!! :D Thanks kinke

Re: DMD metaprogramming enhancement

[Aliak via Digitalmars-d-announce]

On Friday, 26 April 2019 at 06:29:04 UTC, Simen Kjærås wrote:

On Thursday, 25 April 2019 at 23:41:32 UTC, Suleyman wrote:

[...]


You have no idea how happy I am to hear this has been fixed! So 
many of my designs have been hamstrung by 5710, and it's been 
around since the dawn of time.


--
  Simen


Boh, there’s a revert under discussion :( - 
https://github.com/dlang/dmd/pull/9702 ( not merged yet but 路‍♂️)

Re: DMD metaprogramming enhancement

[Aliak via Digitalmars-d-announce]

On Thursday, 25 April 2019 at 23:41:32 UTC, Suleyman wrote:

Hello everyone,

I am happy to announce that in the next DMD release you will be 
able to more freely enjoy your metaprograming experience now 
that a long-standing limitation has been lifted.


You can now instantiate local and member templates with local 
symbols.


Example:
---
struct S
{
private int _m;
void exec(alias fun)()
{
fun(_m);
}
}

unittest
{
int localVar;

void set(int i)
{
localVar = i;
}

auto obj = S(10);
obj.exec!set();   // no error or warning

assert(localVar == 10);
}
---

I hope you enjoy!


Noice! Finally indeed. thank you! :D

Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come

[aliak via Digitalmars-d-announce]

On Monday, 18 March 2019 at 10:05:40 UTC, Jacob Carlborg wrote:

On 2019-03-17 21:09, Per Nordlöw wrote:


I thought that already is the case...


No, the official binaries are built with DMD as the host 
compiler.


How come they're not built with LDC (for example) and then 
distributed? I'd think it'd be shit tonnes more performant?

Re: Release D 2.085.0

[aliak via Digitalmars-d-announce]

On Sunday, 3 March 2019 at 17:44:21 UTC, Andre Pany wrote:

On Sunday, 3 March 2019 at 14:01:03 UTC, aliak wrote:

On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:

Glad to announce D 2.085.0, ♥ to the 49 contributors.

This release comes with context-aware assertion messages, 
lower GC memory usage, a precise GC, support to link custom 
GCs, lots of Objective-C improvements¹, and 
toolchainRequirements for dub. This release also ended 
official support for OSX-32.


http://dlang.org/download.html 
http://dlang.org/changelog/2.085.0.html


¹: There is a pending Objective-C fix
(https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 
but will

be released with 2.085.1 soon (~1.5 weeks).

-Martin


I'm not sure what's happening here but with 2.085.0 I'm 
getting linking errors all of a sudden. Could it be dub?


To reproduce, init a new dub project, add dependency on 
"ddash" and use this main:


import std.stdio;

void main() {
import ddash: stringifySeperatedBy;
writeln([1, 2, 3].stringifySeperatedBy("."));
}

Linking results in:

Linking...
Undefined symbols for architecture x86_64:
  "__D5ddash12__ModuleInfoZ", referenced from:
  __D3app12__ModuleInfoZ in blah.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v 
to see invocation)



When I set compiler back to 2.084.1 then:

Linking...
To force a rebuild of up-to-date targets, run again with 
--force.

Running ./blah
1.2.3

Any ideas?


After upgrading DMD in most cases I have to either delete the 
cached dub packages in the user directory or execute dub with 
the --force argument to rebuild all dependent dub packages.
In theory dub should be able to recognize a changed compiler 
version and automatically rebuild all dependencies but I do not 
know how hard it would be to implement this.


Kind regards
Andre


Thanks for the tip, but it was on deployment on clean machines so 
everything is downloaded from scratch. No caches as far as i 
could tell. Double checked on my machine as well and still the 
same.


I did however notice that it also works on 2.085.0 if i import it 
a different way:


i.e. this works:

void main() {
 	import ddash.functional: stringifySeperatedBy; // difference is 
in import statement

writeln([1, 2, 3].stringifySeperatedBy("."));
}

So I guess maybe dub is off somewhere, or something which 
shouldn't have been working was.

Re: Release D 2.085.0

[aliak via Digitalmars-d-announce]

On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:

Glad to announce D 2.085.0, ♥ to the 49 contributors.

This release comes with context-aware assertion messages, lower 
GC memory usage, a precise GC, support to link custom GCs, lots 
of Objective-C improvements¹, and toolchainRequirements for 
dub. This release also ended official support for OSX-32.


http://dlang.org/download.html 
http://dlang.org/changelog/2.085.0.html


¹: There is a pending Objective-C fix
(https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 
but will

be released with 2.085.1 soon (~1.5 weeks).

-Martin


I'm not sure what's happening here but with 2.085.0 I'm getting 
linking errors all of a sudden. Could it be dub?


To reproduce, init a new dub project, add dependency on "ddash" 
and use this main:


import std.stdio;

void main() {
import ddash: stringifySeperatedBy;
writeln([1, 2, 3].stringifySeperatedBy("."));
}

Linking results in:

Linking...
Undefined symbols for architecture x86_64:
  "__D5ddash12__ModuleInfoZ", referenced from:
  __D3app12__ModuleInfoZ in blah.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)



When I set compiler back to 2.084.1 then:

Linking...
To force a rebuild of up-to-date targets, run again with --force.
Running ./blah
1.2.3

Any ideas?

Re: DIP 1016--ref T accepts r-values--Formal Assessment

[Aliak via Digitalmars-d-announce]

On Friday, 1 February 2019 at 14:41:52 UTC, 12345swordy wrote:

On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:

On 01.02.19 10:10, aliak wrote:

[...]


http://wilzbach.github.io/d-dip/DIP24

I'm not sure your rewrite is good though, because it does not 
preserve aliasing during the function call.
Not only that, but C# forbids you passing properties as an 
ref/out parameter.
(The properties should be redefined as accessor, such that you 
can't take the address of it)

-Alex


By properties I mean accessors? I don’t mean normal fieldsat 
least. Or does c# have a distinction between normal member 
variables, properties, and accessors?

Re: DIP 1016--ref T accepts r-values--Formal Assessment

[aliak via Digitalmars-d-announce]

On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:

On 01.02.19 10:10, aliak wrote:




Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a 
getter? For it not to be a compile error pt.x should also have 
a setter, in which case the code needs to be lowered to 
something else:


{
   auto __temp = pt.x;
   doubleMyValue(__temp);
   pt.x = __temp;
}

I believe this is something along the lines of what Swift and 
C# do as well.


Or something... a DIP to fix properties anyone? :)


http://wilzbach.github.io/d-dip/DIP24

I'm not sure your rewrite is good though, because it does not 
preserve aliasing during the function call.


You mean if __temp is modified in the doubleMyValue and pt.x 
aliases something else? Or? Wouldn't the assignment back "just 
work"?


And is there a rewrite that would work then?

Re: DIP 1016--ref T accepts r-values--Formal Assessment

[aliak via Digitalmars-d-announce]

On Thursday, 31 January 2019 at 21:50:32 UTC, Steven 
Schveighoffer wrote:

On 1/31/19 4:46 PM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 18:31:22 UTC, Steven 
Schveighoffer wrote:

BTW, the DIP discusses how to annotate these rare situations:

int doubleMyValue(ref int x) { ... }
@disable int doubleMyValue(int x);



I don't think that's a solution. The problem is in the getter 
method, not in doubleMyValue. If nothing else, since the DIP 
is designed to work on existing functions, it could happen on 
doubleMyValue functions which would be both designed by and 
used by people completely unaware of DIP-1016.


How is the problem not in doubleMyValue? It's sole purpose is 
to update an lvalue. It is the perfect candidate to mark with 
@disable for rvalues.


-Steve


Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a 
getter? For it not to be a compile error pt.x should also have a 
setter, in which case the code needs to be lowered to something 
else:


{
  auto __temp = pt.x;
  doubleMyValue(__temp);
  pt.x = __temp;
}

I believe this is something along the lines of what Swift and C# 
do as well.


Or something... a DIP to fix properties anyone? :)

Also, this applies to a much wider variety of operations on 
properties that return rvalues and not just on functions calls no?


struct B {
int x;
}
struct A {
  B _b;
  @property B b() { return _b; }
}

void main() {
A a;
a.b.x += 1;
writeln(a.b.x); // 0
}

Re: My Meeting C++ Keynote video is now available

[aliak via Digitalmars-d-announce]

On Tuesday, 15 January 2019 at 06:57:28 UTC, Paul Backus wrote:

On Tuesday, 15 January 2019 at 05:18:45 UTC, aliak wrote:

Quote from article:

"The languages with the strongest positive coefficients - 
meaning associated with a greater number of defect fixes are 
C++, C, and Objective-C, also PHP and Python.  On the other 
hand, Clojure, Haskell, Ruby and Scala all have significant 
negative coefficients implying that these languages are less 
likely than average to result in defect fixing commits."


Does this take into account the experience of the programmers 
writing in each language? Given their relative popularity, I 
imagine PHP and Python have many more beginning programmers 
writing code in them than Haskell and Clojure.


Not that I saw in the paper no. But that is a good point.

Re: My Meeting C++ Keynote video is now available

[aliak via Digitalmars-d-announce]

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu 
wrote:

https://youtube.com/watch?v=tcyb1lpEHm0

If nothing else please watch the opening story, it's true and 
quite funny :o).


Now as to the talk, as you could imagine, it touches on another 
language as well...



Andrei


Awesome talk! As usual.

Regarding this quote: "The ruby guy next to you is writing just 
as crappy code..."  I don't think that's really correct. The 
reference is code complete, which is published in 93 (i.e. no 
java, no ruby, before the stl even?) and i believe (just googled 
this so may be wrong) the reference in that book is from a 1977 
paper on programmer quality and productivity and the 2004 edition 
of code complete changes the number form 15 to 50 / 1000 to 1 .. 
25 / 1000, but references the same paper afaik.


Here's a more recent study: 
http://rayb.info/uploads/cacm2017-lang.pdf


Here's an article that summarizes it -> 
https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html


Quote from article:

"The languages with the strongest positive coefficients - meaning 
associated with a greater number of defect fixes are C++, C, and 
Objective-C, also PHP and Python.  On the other hand, Clojure, 
Haskell, Ruby and Scala all have significant negative 
coefficients implying that these languages are less likely than 
average to result in defect fixing commits."


Also this is more anecdotal, but for example going from 
objective-c to swift, the number of non-application-specific bugs 
per line (regardless of whether or not that's even a good measure 
路‍♂️), i feel, has gone down by an exaggerated order of magnitude.


Cheers,
- Ali

Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System

[aliak via Digitalmars-d-announce]

On Wednesday, 5 December 2018 at 23:18:12 UTC, rikki cattermole 
wrote:

On 06/12/2018 10:18 AM, aliak wrote:

"Weka is a name of a Machine learning product from New Zealand.


Weka is the company that produced Lord of the Rings here in NZ.


*Weta.

Bless them :D

Weka is a set of ML tools from waikato uni => 
https://www.cs.waikato.ac.nz/ml/weka/

Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System

[aliak via Digitalmars-d-announce]

On Wednesday, 5 December 2018 at 19:59:46 UTC, Joakim wrote:
On Wednesday, 5 December 2018 at 09:04:49 UTC, Walter Bright 
wrote:

#4 on HackerNews front page!

https://news.ycombinator.com/

33 points at the moment!


Now one of the top-voted links on the front page of HN.

I'd just like to point out that Andrei put Liran and I together 
to do this interview in summer '17- though I had emailed Liran 
about doing one in '15 and never got a response- and he finally 
got some time to respond this summer.


Now I just need Andrei to finally do an interview, which he's 
been putting off for even longer. :)


Awesome work!

Question about one of the comments, because I don't understand 
the hardware aspect of things. this one: 
https://news.ycombinator.com/item?id=18607297


Pasted here:

"Weka is a name of a Machine learning product from New Zealand.
The IBM system had 24xHGST N200 SSD, 830 000 random read, 200 000 
random write. that is 24 * 200 000 IOPS=4.8Million random writes.


The Matrix system had 64x1.2TB Micron 9100 SSDs. 750 000 random 
read, 300  random writes. 64 * 300 000=19.2 Million IOPS


Ok so you have benchmarked hardware with 4.8 Million write ops vs 
19.2 Million write ops."


Anyone know if that last line is correct?

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

[aliak via Digitalmars-d-announce]

On Tuesday, 13 November 2018 at 09:17:51 UTC, Walter Bright wrote:

On 11/13/2018 12:23 AM, aliak wrote:

Doesn't the above miss a step, and wouldn't it be:

1) A.a => 
2) A.a => 



So basically for the f(short) path you have 3 steps instead of 
2 for the f(int) path.


So does it matter how many implicit conversions need to happen 
before D stops trying? Or is it basically convert as long as 
you can? Does D actually do a "find the shortest path via 
implicit conversions to an overload" algorithm?


It is not a shortest path algorithm. It's simply the enum is 
converted to the base type and the base type is matched against 
the parameter type.


Ok, thanks!



One could have  be treated as 
"better than" , and 
it sounds like a good idea, but even C++, not known for 
simplicity, tried that and had to abandon it as nobody could 
figure it out once the code examples got beyond trivial 
examples.


Interesting. This seems simpler intuitively (shorter path, 
pick it), so I'm wondering if there're any links you can point 
to that describe what these problems were?


No, I simply remember the discussions about it in the early 
90's. Yes, it seems to intuitively make sense, but if you look 
at real C++ code and try to figure it out, it's a nightmare. 
There can also be multiple paths of conversions, and loops in 
those paths. There's a quadratic problem when there are 
multiple parameters.


Bummer. At least if this enum : int case is fixed that doesn't 
seem like it's hard to work out in my head at least - but I guess 
I'm missing some edge case maybe, but I can't figure it out.


Pus, it seems to work as "expected" with alias this. So I kinda 
wonder what reasons there could be to not make it work as 
expected for other scenarios.


struct B {
enum A : int { a }
alias b = A.a;
alias b this;
}

void f(short) {}
void f(int) {}

f(B()); // does what anyone would expect

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

[aliak via Digitalmars-d-announce]

On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:

On 11/12/2018 12:34 PM, Neia Neutuladh wrote:

Tell me more about this "consistency".


int f(short s) { return 1; }
int f(int i) { return 2; }

enum : int { a = 0 }
enum A : int { a = 0 }

pragma (msg, f(a));   // calls f(int)
pragma (msg, f(A.a)); // calls f(short)

I.e. it's consistent.

Here's how it works:

f(a): `a` is a manifest constant of type `int`, and `int` is an 
exact match for f(int), and f(short) requires an implicit 
conversion. The exact match of f(int) is better.


f(A.a): `a` is an enum of type `A`. `A` gets implicitly 
converted to `int`. The `int` then gets exact match to f(int), 
and an implicit match to f(short). The sequence of conversions 
is folded into one according to:


=> conversion>
  => conversion>


Doesn't the above miss a step, and wouldn't it be:

1) A.a => 
2) A.a => 



So basically for the f(short) path you have 3 steps instead of 2 
for the f(int) path.


So does it matter how many implicit conversions need to happen 
before D stops trying? Or is it basically convert as long as you 
can? Does D actually do a "find the shortest path via implicit 
conversions to an overload" algorithm?





One could have  be treated as 
"better than" , and 
it sounds like a good idea, but even C++, not known for 
simplicity, tried that and had to abandon it as nobody could 
figure it out once the code examples got beyond trivial 
examples.


Interesting. This seems simpler intuitively (shorter path, pick 
it), so I'm wondering if there're any links you can point to that 
describe what these problems were?


Cheers,
- Ali

Re: lodash like utility/algorithms library for D

[aliak via Digitalmars-d-announce]

On Monday, 1 October 2018 at 00:51:24 UTC, Paul Backus wrote:

On Sunday, 30 September 2018 at 22:17:05 UTC, aliak wrote:
On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus 
wrote:
I agree that this is useful, but why not just return a naked 
`SumType!(string, JSONError)` in that case? Is there some 
additional value added by the `Expect` wrapper that I'm not 
seeing?


That's an option as well I guess. But then you'd need to rely 
on convention and you couldn't do SumType!(int, int) f(), and 
Expect also gives you some more purposeful APIs that makes the 
code's intent clear. Plus I'm considering range behavior as 
well.


Is being able to write `Expect!(int, int)` actually desirable, 
though? It seems to me like being forced to write something 
like `SumType!(int, ErrorCode)` to distinguish the two cases 
would be a good thing, even if ErrorCode itself is just a 
renamed int (e.g., `struct ErrorCode { int code; alias code 
this; }`).


Hard to say, I would try to avoid it if possible, but why should 
it not be allowed if someone wants it? For now it feels like an 
opinionated restriction that I think is better left out of 
generic code when possible - at least for now. If it turns out 
otherwise I'll change it - this is all still quite experimental 
in me head.


Using SumType to denote success and failure would be more of a 
convention though and would make for more "huh?" moments for 
readability/maintainability, IMO. I like typing intents.


And being able to add an "alias this" in Expect for e.g. might be 
nice. Or if I want to add a "make match has exactly two handlers" 
so that you have to handle both cases would also be a plus.





I guess you could argue that `return 
typeof(return).unexpected(...)` is better than `return 
typeof(return)(ErrorCode(...))`, which is what you'd get with 
SumType, but they look equally ugly to me. What's really needed 
to make that look nice is implicit constructors.


*nods*



Treating an Expect as a range basically turns it into an 
Optional, in the sense that it collapses any error information 
it contains down to the boolean of empty vs not-empty. In fact, 
probably the easiest way to add range behavior to Expect would 
be to add a method that returns an Optional containing the 
expected value, since Optional already has range behavior.




Good point. Agreed!

Could you also return a union voldermort type then instead of 
a SumType?


Raw unions in D are horrifically unsafe, so I wouldn't 
recommend it. If you want a voldemort SumType, you can get one 
like this:


auto f()
{
struct Result { SumType(T, U) data; alias data this; }
return Result(...);
}

Re: lodash like utility/algorithms library for D

[aliak via Digitalmars-d-announce]

On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus wrote:

On Saturday, 29 September 2018 at 12:40:14 UTC, aliak wrote:
I.e. by allowing you to define the unexepcted you could for 
instance:


enum JSONError {
  invalidKey, notString, notNumber
}

auto a = parse(jsonData);

a.getAsString("key").match!(
(string value) => // yay
(JSONError error) => // small domain of what went wrong
);


I agree that this is useful, but why not just return a naked 
`SumType!(string, JSONError)` in that case? Is there some 
additional value added by the `Expect` wrapper that I'm not 
seeing?


That's an option as well I guess. But then you'd need to rely on 
convention and you couldn't do SumType!(int, int) f(), and Expect 
also gives you some more purposeful APIs that makes the code's 
intent clear. Plus I'm considering range behavior as well.


Could you also return a union voldermort type then instead of a 
SumType?

Re: lodash like utility/algorithms library for D

[aliak via Digitalmars-d-announce]

On Saturday, 29 September 2018 at 12:44:38 UTC, aliak wrote:
On Saturday, 29 September 2018 at 01:40:34 UTC, Robby Marki 
wrote:

On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:

[...]


In this example
https://aliak00.github.io/ddash/ddash/functional/try_.html

where does the match function come from?
I get this error when trying to compile:
onlineapp.d(16): Error: no property match for type int
/dlang/dmd/linux/bin64/../../src/phobos/std/algorithm/iteration.d(500):
instantiated from here: MapResult!(__lambda1, int[])
onlineapp.d(15):instantiated from here: map!(int[])


Haha ok I'm a bit stumped right now. That example is wrong, so 
you get the correct error, but it actually compiles on me 
machine right now.


I changed Try.front to return the expected return value of a 
tryable function. And in that example that would clearly be an 
int. So there is no "match" on type int is what I should be 
seeing as well. But for some reason that I'm going to have to 
dig in to, it's compiling a running in the actual project code 
O_o.


Sorry no, it is working as expected. I see that you have an error 
on onlineapp.d(16) ... are you using run.dlang.io?


I just tried a new project and it compiles fine.

Match is part of the Try type.

Cheers,
- Ali

Re: lodash like utility/algorithms library for D

[aliak via Digitalmars-d-announce]

On Saturday, 29 September 2018 at 01:40:34 UTC, Robby Marki wrote:

On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:

Hi,

I've been working for fun on a library [0] that is inspired by 
a library from the javascript world called lodash [1]. I 
basically liked the flexibility and thought I'd try and 
implement a few things as it was about the time I started 
learning D. It basically tried to do the same with algorithms 
as in lodash but adds the usage of Optional!T and Expect!(T, 
U) as ways to returns results.


[...]


In this example
https://aliak00.github.io/ddash/ddash/functional/try_.html

where does the match function come from?
I get this error when trying to compile:
onlineapp.d(16): Error: no property match for type int
/dlang/dmd/linux/bin64/../../src/phobos/std/algorithm/iteration.d(500):
instantiated from here: MapResult!(__lambda1, int[])
onlineapp.d(15):instantiated from here: map!(int[])


Haha ok I'm a bit stumped right now. That example is wrong, so 
you get the correct error, but it actually compiles on me machine 
right now.


I changed Try.front to return the expected return value of a 
tryable function. And in that example that would clearly be an 
int. So there is no "match" on type int is what I should be 
seeing as well. But for some reason that I'm going to have to dig 
in to, it's compiling a running in the actual project code O_o.

Re: lodash like utility/algorithms library for D

[aliak via Digitalmars-d-announce]

On Friday, 28 September 2018 at 17:33:04 UTC, Paul Backus wrote:

On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:

Hi,

[...]


Lots of good stuff here!

I'm curious about your approach to `Expect`, since I've written 
a version of it myself. How useful have you found being able to 
use unexpected values of any type, as opposed to just 
exceptions?


Thanks! Still all rough around the edges.

About Expect, I've found that being able to define a set of 
expected unexpected values is quite practical, and if they're all 
based on the class Exception then there're two problems. 1, it's 
a class so it comes with all those constraints. 2, there's no way 
to close the value domain over the unexpeceted (if that makes 
sense?). Also some functions (take the classic errono catastrophy 
in C) may want to return error codes as unexpected values that 
are ints, and at the same time have a valid value as an int as 
well.


I.e. by allowing you to define the unexepcted you could for 
instance:


enum JSONError {
  invalidKey, notString, notNumber
}

auto a = parse(jsonData);

a.getAsString("key").match!(
(string value) => // yay
(JSONError error) => // small domain of what went wrong
);

A bit contrived here, but it actually comes form production code 
(https://github.com/schibsted/account-sdk-ios/blob/master/Source/Core/JSON/JSONObject.swift).


Different language of course, but in that repo there's a type 
called Result, which is basically Expect. But in swift you have 
something called protocols, which lets you contstrain template 
types (in a different way than isInputRange works). And there's a 
standard protocol called Error. So you can do:


Result where JSONError is defined as:

struct JSONError: Error {} // conforms to error protocol.

There's actually a D DIP which could allow for similar behavior: 
https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md


But for now since D does not have that.

Another approach would be duck typying I guess. And make a 
isExceptionType trait in D that makes sure some functions are 
supported (i.e. msg, and that it can be constructed with 
__FILE__, __LINE__ ). I have not thought out completely how those 
semantics would work, just thinking out loud right now.

Re: lodash like utility/algorithms library for D

[aliak via Digitalmars-d-announce]

On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:

Hi,
[...]


PS Docs: https://aliak00.github.io/ddash/ddash/algorithm.html

lodash like utility/algorithms library for D

[aliak via Digitalmars-d-announce]

Hi,

I've been working for fun on a library [0] that is inspired by a 
library from the javascript world called lodash [1]. I basically 
liked the flexibility and thought I'd try and implement a few 
things as it was about the time I started learning D. It 
basically tried to do the same with algorithms as in lodash but 
adds the usage of Optional!T and Expect!(T, U) as ways to returns 
results.


The readme has some more info on how things were approached: 
https://github.com/aliak00/ddash


I've also been inspired by Scala, so stuff from there also got 
thrown in (e.g. Try). I still consider this library largely 
experimental, but it's turning out nice IMO.


Anyway, code:

import std.experimental.all;

void main() {
import ddash:
flatMap,
try_,
cond,
compact,
isFalsey,
differenceBy;

// This could throw.
alias toInt = (string str) => str.to!int;

// Call toInt using try_ and flatMap so that you only have
// valid data points
alias parseDataSet = (arr) => arr.flatMap!(try_!toInt);

auto cosmicPoints = dataSets
.map!parseDataSet
 // Get rid of data sets that are empty
.compact!isFalsey
// Convert them to CosmicDataPoint type
.map!(arr => CosmicDataPoint(arr.sum))
// Remove the known dead-end values by getting a 
difference set

// based on the "value" member type
// This can also be:
// .difference!((a, b) => a.value == b.value)(...)
// Or in the case of a D value type just:
// .difference!(...)
.differenceBy!"value"(knownDeadEndValues);

assert(cosmicPoints.walkLength == 3);

// Pattern match on CosmicDataPoint types and process 
accordingly

alias process = cond!(
CosmicDataPoint(29), processBlackMatter,
CosmicDataPoint(30), processGravitationalWave,
a => a.value > 30 && a.value < 100, processPromisingData,
a => writeln("This data is useless: ", a),
);

cosmicPoints.each!process;
}

// Simulated data sets that result in CosmicDataPoint
immutable dataSets = [
["2", "3", "2"],// Produces CosmicDataPoint(7)
["22", "~1", "7"],  // Produces CosmicDataPoint(29)
["!$", "88", "3"],  // Produces CosmicDataPoint(91)
["junk", "junk", "junk"],   // All junk data points
["99", "44"],   // Produces CosmicDataPoint(143)
];

// A cosmic data point
static struct CosmicDataPoint {
int value;
}

// Simulate values that you know occur but are a dead end
auto knownDeadEndValues = [1, 7, 42].map!(a => 
CosmicDataPoint(a));


// Define some data processing functions
static void processBlackMatter(CosmicDataPoint) {
writeln("processing black matter discovery");
}
static void processGravitationalWave(CosmicDataPoint) {
writeln("processing gravitational wave");
}
static void processPromisingData(CosmicDataPoint) {
writeln("processing data that's close");
}

Cheers,
- Ali

[0] https://ddash.dub.pm
[1] https://lodash.com/

Re: Copy Constructor DIP and implementation

[aliak via Digitalmars-d-announce]

On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis 
wrote:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via 
Digitalmars-d- announce wrote:
This will break compilation of current code that has an 
explicit copy constructor, and the fix is simply to add the 
attribute @implicit.


In that case, why not just use a transitional compiler switch? 
Why force everyone to mark their copy constructors with 
@implicit forever? The whole point of adding the attribute was 
to avoid breaking existing code.


- Jonathan M Davis


Well one breaks compilation and the other is silent code changes. 
And No.compilerSwitch > Yes.compilerSwitch when possible.


I'm actually not strongly for @implicit btw.

Re: Copy Constructor DIP and implementation

[aliak via Digitalmars-d-announce]

On Monday, 17 September 2018 at 23:32:39 UTC, Jonathan M Davis 
wrote:
On Monday, September 17, 2018 5:07:22 PM MDT Manu via 
Digitalmars-d-announce wrote:

[...]


Except that @implicit could be introduced for other 
constructors without having it on copy constructors, and the 
fact that copy constructors will require it is just going to 
cause bugs, because plenty of folks are going to forget to use 
it and end up with the default copying behavior instead of 
their custom copy constructor being used. Good testing should 
find that pretty quickly, but it's almost certainly going to be 
a common bug, and it has no need to exist. It's all there in 
order to avoid breaking code that's likely only theoretical and 
not something that actual D code bases have done. And if there 
is a stray code base that did it, it's certainly going to be in 
the extreme minority, and the code will almost certainly work 
as a proper copy constructor anyway, since that's pretty much 
the only reason to write such a constructor. So, we'd be trying 
to avoid breaking very rare code by introducing a feature that 
will definitely cause bugs. IMHO, it would be _far_ better to 
just use a transitional -dip* compiler flag like we have with 
other DIPs. It would also give us the benefit of being able to 
bang on the implementation a bit before making it the normal 
behavior.


We can still add @implicit to other constructors for implicit 
construction with a later DIP (assuming that Walter and Andrei 
could be convinced of it). I don't see how having it on copy 
constructors really helps with that. It just means that the 
attribute would already be there, not that it would necessarily 
ever be used for what you want, and _not_ having it on copy 
constructors wouldn't prevent it from being used for implicit 
construction if such a DIP were ever accepted. So, while I 
understand that you want implicit construction, I think that 
it's a huge mistake to tie that up into copy constructors, 
particularly since it really doesn't make sense to have copy 
constructors that aren't implicit, and having @implicit for 
copy constructiors is going to cause bugs when it's forgotten.


- Jonathan M Davis


I think this can be made in to a compiler error.

The logic would be if there is any copy constructor defined (by 
copy constructor I mean a constructor that gets passed an object 
that can be used to construct typeof(this) - so ignore definition 
in DIP), then default copy construction is a compiler error 
unless an @implicit copy constructor is defined.


struct A {
  this(ref A) {}
}

A a;
A b = a; // error, cannot implicitly copy because an explicit one 
is provided

A c = A(a); // ok

This will break compilation of current code that has an explicit 
copy constructor, and the fix is simply to add the attribute 
@implicit.

Re: expectations 0.1.0

[aliak via Digitalmars-d-announce]

On Monday, 3 September 2018 at 06:00:06 UTC, Thomas Mader wrote:
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev 
wrote:

There are generally two classic approaches to error handling:


std::expected is not the only thing on this topic going on in 
C++.

There is also the proposal from Herb Sutter [1].
It's not a library solution and changes even the ABI but it's 
an interesting approach.
He also tries to get compatibility into C via an extension. 
(See 4.6.11 in [1])


[1] 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf


This would be great to have in D. Swift [0] has something 
similar, and personally after using it for a few years, I can say 
that I've seen next to no unhandled exception errors in iOS code 
at least.


[0] 
https://www.mikeash.com/pyblog/friday-qa-2017-08-25-swift-error-handling-implementation.html

Re: expectations 0.1.0

[aliak via Digitalmars-d-announce]

On Monday, 3 September 2018 at 06:49:41 UTC, Paul Backus wrote:
To me, the only acceptable choices are for `Expected!void` to 
have the same lazy semantics as `Expected!T`, or for 
`Expected!void` to be removed altogether. Having one 
specialization be lazy and one be eager would be a nightmare 
for anyone trying to use the library. For the reasons Vladimir 
brought up, I'm leaning toward removal--without something like 
Rust's `#[must_use]` attribute, it seems like `Expected!void` 
is likely to do more harm than good.


I'm leaning on agreeing with removal of Expected!void as well

When we get opPostMove then maybe Expected!void can throw on a 
move or a copy if the result was a failure. This would also not 
allow the error to be ignored as it'd throw.


Or... can it throw in ~this() if it was not checked?

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

[aliak via Digitalmars-d-announce]

On Monday, 27 August 2018 at 05:22:30 UTC, FeepingCreature wrote:

- Consider a short form for "dispatch". Purely for convenience:
   e.g.: john.d.residence.d.numberOfRooms;


Why not .get, like Nullable?
As long as you never alias it to this... ;)


Mmm... get is indicative of getting the value. But we're not 
getting a value here, we're dispatching/propagating to the 
underlying type. I just wish we could figure out some way to use 
operators to some degree in D :(

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

[aliak via Digitalmars-d-announce]

On Wednesday, 22 August 2018 at 22:49:52 UTC, Paul Backus wrote:

On Wednesday, 22 August 2018 at 22:11:05 UTC, aliak wrote:

On Monday, 20 August 2018 at 19:52:53 UTC, jmh530 wrote:


It's interesting that both sumtype and optional have match 
templates. Maybe scope to combine these projects?


That'd be cool. Optional uses .match on a "some" or "none" 
range, while SumType uses it on a union. So ideas on how to go 
about it?


In theory, Optional(T) could be implemented as a wrapper around 
SumType!(T, None), which would let it reuse SumType's match 
method. I'm not sure if it'd be worth the effort to convert at 
this point, though.


THis is true. And might be interesting to try out actually. Can 
you access the types in a SumType via index?


I'm thinking because Optional behaves like a range, and I guess 
I'd define a SumType!(T, None), then a rough outline may be:


struct None {}
immutable none = None();

struct(T) {
  SumType(T, None) opt;
  T front() {
return opt[0]; // what to do here?
  }
}

Or I guess I should maybe do it like this?:

return opt.match!(
  (T val) => val,
  (None) => T.init,
);

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

[aliak via Digitalmars-d-announce]

On Monday, 20 August 2018 at 09:16:18 UTC, ikod wrote:

On Thursday, 16 August 2018 at 16:20:09 UTC, aliak wrote:

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:

It's also @nogc and @safe


No it's not. Not dispatching at least. Dunno why though. Seems 
safey is because taking an address. Nogc will have to look in 
to.


Hello!

please, help, how can I use match in @nogc code:

import optional;

void main() @nogc {
Optional!int i = 1;
bool b = true;
i.match!(
(v) => b,
() => false
);
}

fails to compile:
source/app.d(3,6): Error: function `D main` is @nogc yet 
allocates closures with the GC
source/app.d(7,9):app.main.__lambda1 closes over 
variable b at source/app.d(5,10)


Thanks!


Hi, it's because the lambda "(v) => b" allocates. Same would 
happen with any other function that takes an alias to a lambda 
and that lambda causes a closure allocation.


Changing this to "(int v) => b" seems to make the compiler infer 
@nogc though and it compiles.


But it's still a delegate, so I'm not sure why that works and not 
sure in which situations D infers a nogc delegate.


The same thing does not work for algorithm.map for e.g.

Cheers
- Ali

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

[aliak via Digitalmars-d-announce]

On Friday, 17 August 2018 at 06:59:48 UTC, Petar Kirov 
[ZombineDev] wrote:

On Thursday, 16 August 2018 at 18:10:38 UTC, jmh530 wrote:

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:

Hi

See: https://optional.dub.pm

I've totally revamped the Optional type and am now quite 
happy with. It has a range interface and safe dispatching and 
can be used to 1) avoid null dereferencing, 2) have non-null 
guarantees, and 3) show clear intent where there may or may 
not be a value. It's also @nogc and @safe and mutation of the 
original object during safe dispatching works as well.




The readme.md page looks great. You might mention that it 
works with @nogc and @safe (I presume Optional and NotNull).


One question: Suppose there was a @weaksafe that has all the 
same features @safe except that it relaxed the requirement of 
"No taking the address of a local variable or function 
parameter." so that you could take the address of a NotNull 
variable. Are there any reasons why this would be unsafe? I 
imagine NotNull requires some type of run-time checking, but 
other than that I don't see why not.


Actually "@weaksafe" already exists in the form of `@safe` + 
`-dip1000` - you can take the address of a local variable in 
`@safe` code and then you get a `scope`-ed pointer, which 
you're not allowed to escape.


Right! There's that. That would most certainly help here.

So the first non-safety part of Optional comes from the dispatch 
function. To support mutations, the pattern is basically:


struct Optional(T) {
  T value;
  auto dispatch() inout {
return inout Dispatcher();
  }
}

Now the thing is, the Dispatcher type is actually disabled on 
copying, construction and identity assignment. So I wonder if 
this can be marked @trusted in theory. Since the address never 
escapes from a Dispatcher object.


And the other part is when two addresses are compared (which is 
local only): 
https://github.com/aliak00/optional/blob/83edfef7130ec02992ec2986611718f80167234d/source/optional/dispatcher.d#L42

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

[aliak via Digitalmars-d-announce]

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:

It's also @nogc and @safe


No it's not. Not dispatching at least. Dunno why though. Seems 
safey is because taking an address. Nogc will have to look in to.

Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like

[aliak via Digitalmars-d-announce]

On Thursday, 16 August 2018 at 15:38:50 UTC, Paul Backus wrote:

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:

Hi

See: https://optional.dub.pm


Looks great!


auto john = some(new Person());


Would it also work to leave off the `some` here and skip the 
first `dispatch` in the following lines? (i.e., make `john` a 
`Person` rather than an `Optional!Person`)



Thanks!
And aye, it should work fine!

Optional and NotNull version 0.5.0 - swift optional like and scala option like

[aliak via Digitalmars-d-announce]

Hi

See: https://optional.dub.pm

I've totally revamped the Optional type and am now quite happy 
with. It has a range interface and safe dispatching and can be 
used to 1) avoid null dereferencing, 2) have non-null guarantees, 
and 3) show clear intent where there may or may not be a value. 
It's also @nogc and @safe and mutation of the original object 
during safe dispatching works as well.


Some code examples:

===
import optional;
import std.stdio: writeln;

class Residence {
auto numberOfRooms = 4;
}
class Person {
Optional!Residence residence;
}

auto john = some(new Person());

john.dispatch.residence.dispatch.numberOfRooms.writeln; // safe, 
prints "[]"

john.dispatch.residence = new Residence();
john.dispatch.residence.dispatch.numberOfRooms.writeln; // prints 
"[4]"


if (auto res = john.dispatch.residence.unwrap) {
writeln(res.numberOfRooms); // safe, prints "4"
}
===

And since it's a range type as well, you can use it with phobos 
algos (and it provides some primitives found in e.g. scala)


===
import std.algorithm: each;

// Make a function that may or may not parse a string to an int
Optional!int toInt(string str) {
import std.conv: to;
scope(failure) return no!int;
return some(str.to!int);
}

auto x = toInt("1").orElse(0);

toInt("1").each!writeln;

toInt("1").match!(
(i) => writeln(i),
() => writeln("nothing there"),
);
===

The readme contains a lot more details.

Some things that are on me list that I need to think about
- Consider a short form for "dispatch". Purely for convenience:
   e.g.: john.d.residence.d.numberOfRooms;
- Consider an auto dispatch (".autoDispatch"?), so that once you 
start a chain you don't need to write "dispatch again:

   e.g.: john.autoDispatch.residence.numberOfRooms;


Some reasonings for design:
- The dispatcher is a completely separate type because Optional 
is a range type and has it's own functions that would be 
impossible to call on a type T without unwrapping first.
- The "safe dispatcher" proxy contains NO functions so that it 
will never trample over a type T.



Cheers,
- Ali

Re: Bolts 0.4 meta programming library

[aliak via Digitalmars-d-announce]

On Thursday, 2 August 2018 at 12:06:16 UTC, Patrick Schluter 
wrote:

On Thursday, 2 August 2018 at 10:31:02 UTC, aliak wrote:

On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote:

[...]


Thanks! And yes, totally aware of that. I have tried to link 
to relevant forum posts and will try to add more as I go along 
to where the usages were concocted. So I guess those could be 
the motivations?


But it'd also be nice to just use it for a while and get 
feedback and experience with the 
names/APIs/functionalities/etc before adding it to std.meta. 
Though being in std would be ideal of course.



[...]


Dammit! You're right! Thank you for pointing that out.

Art! It's Art! ... or maybe i can use a hipster "is" ... i.e. 
"iz" :p




’tis like in "’Tis the season to be jolly."

https://en.wiktionary.org/wiki/'tis
Ok, Unicode (’ U+2019) in a symbol is not nice but works 
normally in D. :-)


Hehe,  I went with iz, and now the docs for iz reads:

"Iz is is - reason for choosing iz is because is is a keyword"

:-D

Are you sure about being able to use U+2019? I get: Error: 
character 0x2019 is not a valid token

Re: Bolts 0.4 meta programming library

[aliak via Digitalmars-d-announce]

On Thursday, 2 August 2018 at 08:45:33 UTC, John Colvin wrote:

On Thursday, 2 August 2018 at 08:40:55 UTC, John Colvin wrote:
This looks cool. Lots of things that lots of people have 
reimplemented lots of times over the years, but all in one 
place and documented.


2 points:

1) Are you aware of this: 
https://github.com/dlang/phobos/blob/master/std/meta.d ? I 
think if a bunch of good motivating examples are given, making 
this public would be possible. Then everyone would be using 
the same one and your library would truly just be utilities.


Thanks! And yes, totally aware of that. I have tried to link to 
relevant forum posts and will try to add more as I go along to 
where the usages were concocted. So I guess those could be the 
motivations?


But it'd also be nice to just use it for a while and get feedback 
and experience with the names/APIs/functionalities/etc before 
adding it to std.meta. Though being in std would be ideal of 
course.




woops, pressed send too early:

2) I don't think "doth" is synonymous with "is" how you're 
using it. "doth" is for doing, e.g.


"Methinks he doth protest too much" or "This code doth stink" 
is OK


"Green doth a colour" or "strstr doth a function" is not OK.


Dammit! You're right! Thank you for pointing that out.

Art! It's Art! ... or maybe i can use a hipster "is" ... i.e. 
"iz" :p


Cheers,
- Ali

Bolts 0.4 meta programming library

[aliak via Digitalmars-d-announce]

Hi, just a release of a meta programming library 
(https://bolts.dub.pm) that has utilities that I use in personal 
projects, and that I find in phobos, and or in the forums. A 
notable difference is that functions here try to operate on any 
compile time entities if they can be resolved.


I.e.:

int i;
void g0(int) {}
struct S { void g1(int) {} }
alias g2 = (int a) => a;
static assert(isFunctionOver!(g0, int));
static assert(isFunctionOver!(S.g1, 3));
static assert(isFunctionOver!(g2, i));

And there's a "doth" super template that tries to contain most 
things under what I feel is a nicer api ("is" was taken, so i 
looked to Shakespearian gibberish :p) and also allows for easier 
use with meta functions:


E.g.:

int *pi = null;
static assert( doth!3.of!int);
static assert(!doth!pi.nullable);
static assert( doth!((a, b, c, d) => a).functionOver!(int, int, 
int, int));


int i;
import std.meta: allSatisfy;
static assert(allSatisfy!(doth!int.of, 3, 4, int, i));

Here's an example of a gem adapted from inside the forms/phobos 
sources as well:


alias a = AliasPack!(1, 2, 3);
alias b = AliasPack!(4, 5, 6);
alias c = AliasPack!(7, 8, 9);

alias d = staticZip!(a, b, c);

static assert(d.length == 3);

static assert(d.Unpack[0].equals!(1, 4, 7));
static assert(d.Unpack[1].equals!(2, 5, 8));
static assert(d.Unpack[2].equals!(3, 6, 9))

static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 2, 5, 8, 
3, 6, 9));


Cheers,
- Ali

Re: The dub documentation is now on dub.pm

[aliak via Digitalmars-d-announce]

On Thursday, 19 July 2018 at 13:10:01 UTC, Martin Tschierschke 
wrote:

On Thursday, 19 July 2018 at 09:39:04 UTC, Seb wrote:

[...]

Very ++ :-)

There should be a big section for well done dub.sdl / dub.json 
examples.


What about defining "comment" as an special keyword for the 
.json parser inside Dub
(just ignoring the content") to allow some kind comments inside 
.json
In the moment only dub.sdl may be more descriptive with 
#comments.

But many people prefer .json  where no comments are build in.

So allow to write "comment" : "This string will will be parsed 
away",

 may do the difference?

Best regards mt.


Yes! Examples would be awesome. I have a little thing going [1] 
that maybe is usable as a start or something?


[1] https://github.com/aliak00/dub-subpackages

Cheers,
 - Ali

Re: Seeking lecturer - D language (Moscow)

[Aliak via Digitalmars-d-announce]

On Wednesday, 14 March 2018 at 11:44:10 UTC, Simen Kjærås wrote:

https://issues.dlang.org/show_bug.cgi?id=5710 might be worth 
it, even if it means moving from friends and a comfy job in 
Norway...


--
  Simen


!!!  Haha Norway? So up for a Norway D meetup? Oslo? Turns out I 
even work with someone who went to uni with you - Håvard Kindem 
(who also says he’d join for such a meetup).


Email: Ali.akhtarzada@gmail... if you are already or ever are in 
Oslo :)


Cheers

Re: An optional/maybe type with range semantics

[aliak via Digitalmars-d-announce]

On Wednesday, 28 February 2018 at 10:55:38 UTC, Andrei 
Alexandrescu wrote:

On 2/28/18 12:54 PM, Andrei Alexandrescu wrote:

On 2/25/18 8:03 PM, aliak wrote:

Did you take a look at 
https://dlang.org/library/std/range/only.html? -- Andrei


Ah, sorry I missed that you mentioned it. -- Andrei


Yeah about that... Maybe I'm looking at this in the wrong way, 
but I'm not sure I understand how using only would actually work 
now that I think about it. I can haz enlightenment? :o


If I wanted to write (contrived example) a function that may or 
may not produce a result, with an argument that it will use if 
present but can do work without (think servers, async, 
incomplete/partial json data, etc).


// a - there's no Only!T, so I don't have a type to work with
// b - I need to constrain function to element type and input 
range

// c - and what do i do if range has more than one value in it?
auto maybeResult(Range)(Range r)
if (isInputRange!Range && is(ElementType!Range == int))
{
  enforce(r.walkLength <= 1); // should I runtime kill?
  return v.map!(a => a + 1); // do I return a map of all elements?
  return v.take(1).map!(a => a + 1); // do I take(1) since that's 
what this function needs?
  // what do I do with the rest then if I don't have the enforce 
above?

}

And then calling it:

auto a = [1];
a = a.maybeResult; // nope, because you can't know what ranges 
are being used inside.

// So you need to create a new var
auto b = a.maybeResult;

===
With an optional this'd be:

Optional!int maybeResult(Optional!int a) {
  return a + 1;
}

auto a = some(1);
a = a.maybeResult;

Cheers,
- Ali

Re: An optional/maybe type with range semantics

[aliak via Digitalmars-d-announce]

On Tuesday, 27 February 2018 at 11:58:34 UTC, Dukc wrote:

On Monday, 26 February 2018 at 20:04:14 UTC, aliak wrote:
Guess I could do a pointer and call new when i need to store a 
value instead. Or maybe it's better to do it like above and 
store as value type with default value and a boolean at the 
site. Not sure.


You do not need a separate boolean field. If someone assigns 
"none" or calls popFront() just assign the pointer to null. 
When someone queries empty, you check whether the pointer 
points to null.  The default value is easy too: 
typeof(element).init.


Either you misunderstood or my writing was not clear. I meant 
you'd need a boolean if you were using a value type (was just 
speaking out loud as another alternative to a pointer or array)




That's the superior design, because it does not need any excess 
memory for the empty flag.


It means using new, so not sure how superior it is compare to 
storing a value type.

Re: Documentation for any* dub package, any version

[aliak via Digitalmars-d-announce]

On Monday, 26 February 2018 at 18:17:51 UTC, Adam D. Ruppe wrote:
Oh, fixed now. since there's no ddoc at all in that file, it 
should have been skipped, I just had a testing "return true;" 
in the method I forgot to remove.


Nice :D Looks good.

ketmar sent me a patch to parse a .adrdox_ignore file, in the 
same format as gitignore, which I merged but haven't pushed to 
that server yet. I'm not sure that's the exact approach I want 
to take, but something like that will be an option soon too if 
the default doesn't work out.


Awesome. good start at least, and just to throw an approach out 
there for your consideration, a .adrdox.yml file with a 
include/exclude/style/etc keys might be a good way to go.


Yeah, I just need to decide how I want that to look in the repo 
too (if you download adrdox yourself, you can change the 
skeleton.html and style.css files locally. style.css is a bit 
of a mess tho but it can be done, i did a dark color scheme 
here to use as a test. but how to do that on the central host? 
idk yet, maybe it can read a custom file out of the git repo, 
or add some option to dub.json.). but that will prolly be a 
week or two before i get around to it.


Great! Think I'll give the skeleton/style a hack at some point 
indeed. Maybe if it's a central host then styling should just be 
homogeneous across the board as well for consistency and all?


Cheers

Re: An optional/maybe type with range semantics

[aliak via Digitalmars-d-announce]

On Monday, 26 February 2018 at 16:02:58 UTC, Dukc wrote:


I kinda start to see the idea... Granted, nullable is in a way 
a range that can hold exactly one or exactly zero elements. Not 
a bad idea at all.


Aye, ranges do not need nullability indeed. Optional doesn't need 
to adhere to the range spec of course, but it does provide some 
conveniences. There's a d-forum thread here on it actually: 
https://forum.dlang.org/thread/l87ivq$263r$1...@digitalmars.com


There's a link in there on scala's optional type which is a fun 
read.


Here's a bit on the current "brokenness" nature of java's 
optional: 
https://developer.atlassian.com/blog/2015/08/optional-broken/


I like how it specifies intent (on the c++ optional): 
https://www.fluentcpp.com/2016/11/24/clearer-interfaces-with-optionalt/


Boost has a fun write-up on the motivation and design behind its 
optional type (which was incorporated in to the c++ standard): 
http://www.boost.org/doc/libs/1_66_0/libs/optional/doc/html/index.html


Meta: Is this your stuff btw? -> 
https://github.com/skirino/d-option :) me thinks I may have 
gotten some inspiration from you if so, so thanks!




But shouldn't it store the value internally as a pointer, not 
as an array, to save a bit space? When empty, it would point to 
null.


Guess I could do a pointer and call new when i need to store a 
value instead. Or maybe it's better to do it like above and store 
as value type with default value and a boolean at the site. Not 
sure.

Re: Documentation for any* dub package, any version

[aliak via Digitalmars-d-announce]

On Monday, 26 February 2018 at 14:59:07 UTC, Adam D. Ruppe wrote:
Many of you will already know this from the other thread or 
from my twitter, but I just added a on-demand downloader to my 
dpldocs.info domain to fetch and build docs for any* dub 
package.


Simply go to projectname.dpldocs.info/vX.Y.Z/ and it will 
generate docs for dub package projectname, version X.Y.Z. (If 
you don't specify a version, it will pull the master branch.)


For example:

http://arsd-official.dpldocs.info/arsd.html

master branch for the arsd-official package

or:

http://dplug.dpldocs.info/v6.0.22/dplug.html

6.0.22 of the dplug package.

etc.

I'd like to get the code.dlang.org folks to add the correct 
link to the main package site so people can easily discover 
this just put nofollow on it plz so google doesn't trigger 
generation of pages people don't actually need (the lazy 
generation + caching allows me to host this on a cheap VPS)



It builds the docs using my own doc generator 
 which pulls embedded doc 
comments out of the source.


It isn't 100% compatible with ddoc. For example, this 
user-defined macro was not expanded: 
http://dxml.dpldocs.info/dxml.dom.html#source


But, it builds 99% of Phobos so it can probably build your 
project too! And get the ease of adrdox navigation and 
legibility.


Moreover, if you want to embrace it, you can use all the 
features described here: 
http://dpldocs.info/experimental-docs/adrdox.syntax.html except 
for the LaTeX math generation (that's not installed on the dub 
doc server I set up).


You can group functions like seen here: 
http://dpldocs.info/experimental-docs/arsd.nanovega.html and 
use some markdown syntax, and easy [reference] linking and more.




The generated docs may get some customization options in the 
future, like adding a logo, header nav links, or maybe tweaking 
the color scheme. It will probably also start reading 
.gitignore and perhaps a .adrdoxignore file soon to to exclude 
files from generation. I just need to decide the details first 
and it is time to work the day job right now and I want to 
announce sooner rather than later :)



* currently, only github code downloading is actually 
implemented.


This is awesome! Worked great. I use ddox right now (eg: 
https://aliak00.github.io/optional/) and your front page is way 
better and the source links are gold!


Questions: Tried it with optional and undocumented stuff is also 
shown. Will this be the default or? What's the recommended way to 
not have some modules in there at this time, if any?


Currently I have a internal.d (e.g. 
https://github.com/aliak00/optional/blob/master/source/optional/internal.d) which has public imports because I want to include it everywhere in my project and have all files have access to (though I think I may need to read up on access controls and modules cause I've just been winging it).


Thanks for this, with theming support I think I'd switch to this 
in me personal repos at least.


Cheers

An optional/maybe type with range semantics

[aliak via Digitalmars-d-announce]

Alo,

Just finished up a first take on an optional type for D. It's 
essentially a mix of Nullable and std.range.only, but with a lot 
more bells and whistles. I would love to hear any feedback on 
code, or features, or bad design or potential for better designs 
from anyone who's interested :)


Code: https://github.com/aliak00/optional
Dub: https://code.dlang.org/packages/optional
Docs: https://aliak00.github.io/optional/

Things to do:
* Handle dispatching of static fields/method (see code below)
* Implement flatmap/decide if flatmap should be in here
* Figure out what kind of range this should be (currently its 
just an input range - should it be more?)
* Implement some phobos algorithms as returning optionals (e.g. 
countUntil)


Anyway, here's some code to peak at a few of the supported 
features:


auto a = some(3);
auto b = a + 4; // opUnary/Binary/Equals (so far) supported

a = none;
a++ // noop

auto p = no!(int*);
assert(a == *p) // none == none
p = null;
assert(a == *p) // null handled

struct A {
  struct B { void g() {} }
  B f() { return B(); }
}

auto  b = no!(A*);
b.dispatch.f.g // dispatch is safe, noop

b = new A;
b.dispatch.f.g // makes calls now because non empty.

Cheers,
- Ali

Re: Beta 2.079.0

[aliak via Digitalmars-d-announce]

On Thursday, 22 February 2018 at 13:51:18 UTC, Seb wrote:

On Thursday, 22 February 2018 at 13:35:00 UTC, aliak wrote:


barring a revert,


Who says we can't revert it?

https://github.com/dlang/dmd/pull/7939

On the contrary, imho if it's so controversial it should be 
reverted now, s.t. it doesn't accidentally end up in 2.079 and 
we would be stuck with it for a long time.


Touche :)

Though personally I'm actually not against the existence of the 
syntax. I think it does improve signal to noise ration if (like 
many language features) used correctly. And that it feels natural 
to expect it to work.

Re: Beta 2.079.0

[aliak via Digitalmars-d-announce]

On Thursday, 22 February 2018 at 08:52:21 UTC, Timothee Cour 
wrote:

you should also mention an important point:
current syntax disallows importing a simple module foo (with no 
package), eg:


import std.stdio:write,foo; // there's no way to specify a 
module `foo` import std.stdio:write & foo; // ok


I don't care whether it's `|` or `&` but `,` as a module 
separator is 100% broken (and illegible, as you mentioned).




Given that comma is implemented already, and barring a revert, 
can we maybe somewhat unbreak it by allowing:


import mod1: write, .mod2;

So leading dot to say it's a module (if not fully qualified)