Re: DIP 1016--ref T accepts r-values--Community Review Round 1

[meppl via Digitalmars-d]

On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d 
wrote:

...


...
Allowing ref to accept rvalues goes completely against the idea 
that ref is for passing an object so that it can be mutated and 
have its result affect the caller. With this DIP, we'd likely 
start seeing folks using ref all over the place even when it 
has nothing to do with having the function mutating its 
arguments, and that's not only error-prone, but it obfuscates 
what ref was originally intended for.

...



So, if `immutable` would be the default in D, you would be okay 
with "DIP 1016"?  Because then people would have to write `ref 
mutable` for mutation

Re: Copy Constructor DIP

[meppl via Digitalmars-d]

On Thursday, 12 July 2018 at 20:29:43 UTC, Manu wrote:
On Wed, 11 Jul 2018 at 23:55, RazvanN via Digitalmars-d 
 wrote:


> What's wrong with:
> struct S {
>   this(ref S copyFrom);
> }
>
> That looks like a perfectly good copy constructor 
> declaration ;) I'm just saying, the DIP needs to explain 
> this.


That is actually a valid constructor, according to today's
compiler. There
might be code out there that uses this syntax for the 
constructor

and overnight
it will be turned into a copy constructor.


Exactly. Is that a problem?
It probably IS a copy constructor already, what else could it 
be? :)




it can be something else. For example a lifo list pusher. Even if 
it is considered bad design, someone might have done it

Re: Ideas for students' summer projects

[meppl via Digitalmars-d]

On Wednesday, 23 May 2018 at 01:51:35 UTC, Mike Franklin wrote:

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


Let the brainstorming begin!


Make WebAssembly a thing in D.

See 
https://forum.dlang.org/post/ejplfelcqsvjmdvxt...@forum.dlang.org


Currently C++ and Rust dominate that domain.  D could kick some 
web asm there too.


Mike


I am curious about binary size of microservies on webpages. 
D-binaries tend to be bigger and the D garbage collector needs to 
be within them. Then we would have to rely on LLVM drastically 
reducing the binary size of static compiled apps.


If we say "its only for betterc" or "its only for bigger webapps 
and nodejs-webassembly", it would be half assed - and in my 
humble opinion too much of a disadvantage compared to rust. I 
might be wrong of course

Re: extend foreach to work on non-arrays

[meppl via Digitalmars-d]

On Friday, 25 May 2018 at 03:34:43 UTC, IntegratedDimensions 
wrote:

On Friday, 25 May 2018 at 02:43:39 UTC, Jordan Wilson wrote:
On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions 
wrote:

[...]


3rd outcome: noobs like me who read the forums who benefit 
from such discussion.


Of course, you could be as disinterested in the 3rd outcome as 
you are the 1st and 2nd, and that's completely fair.


Jordan






So, I will solve the homework problem for you:

auto max(T)(T t)
{
  baseTypeOf(T) a;
  foreach(a; t)
 a = max(a,t)
  return a;
}

max(3) = 3
max([3,4,5]) = 5




you didnt take your time to give a proper example. That code is 
wrong in multiple ways. People would have to reconstruct your code

Re: extend foreach to work on non-arrays

[meppl via Digitalmars-d]

On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions 
wrote:

Doesn't make any sense?

foreach(a; x)

if x is not an array then a = x and the loop reduces simply and 
function to the case it is not so their can be no harm.


It unifies the concepts so that one does not have to worry if x 
is an array or not and can offer no harm since when x is not an 
array everything simply reduces to an an alias of x.


on the otherhand some programmer might want to get informed buy 
an error-msg, if he accidentally used a non-iteratable variable 
for `foreach`-iteration. To avoid a silent bug

Re: Sealed classes - would you want them in D?

[meppl via Digitalmars-d]

On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:
On Wednesday, May 16, 2018 02:39:22 KingJoffrey via 
Digitalmars-d wrote:
On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis 
wrote:

> ...

...


The best clarification I can find, regarding how D treat's 
private, is from this tiny little sentence (from which, I 
assume, the programmer is now meant to understand it's full 
implications):


"Symbols with private visibility can only be accessed from 
within the same module"


https://dlang.org/spec/attribute.html#visibility_attributes


It specifies what private does quite accurately. If you want 
something that's trying to point out how you might 
misunderstand the spec or what problems you might run into, 
you'll need to read something like Ali's book. The spec is 
telling you how the language works, not trying to tell you how 
you might misunderstand it or what misakes you might make.

...


- Jonathan M Davis


a pitfall-section about 'private' and 'protected' in 
https://dlang.org/spec/class.html wouldnt hurt. KingJoffrey is 
not the first one at all who discovered this corner case 
_afterwards_. I saw it in the forum.
Additionally I am curious about the "you must read a 
book"-statement, if KingJoffrey learned almost anything by 
reading the specification-documentation except for a few pitfalls.

Re: Module-level privacy

[meppl via Digitalmars-d]

On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote:

On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:

[...]


First, this thread was about extending the capabilities of 
classes in D with some new attribute/capability - sealed.


I thought it was first important to point out, in this thread, 
as opposed to a separate thread, that classes in D are already 
problematic, because modules do not respect the encapsulation 
boundaries of classes, and any discussion about further 
extending classes should be approached with great caution - 
because the problem will only become even more entrenched.


Second, writing a DIP is pointless, since Walter likes the idea 
that the module doesn't protect the encapsulation boundary of 
the class. Now if Walter thinks that's fine, what is a DIP 
going to do? I mean really. I have better things to do.


Third, those who responded to my caution are the ones that 
should have created a separate thread, not me.


Finally (and I do mean finally), my concern about the loss of 
the encapsulation boundary of classes in D, has a very real 
impact on the quality and maintainability of software systems 
developed in D. That the designer of D apparently thinks 
otherwise, baffles me.


walter bright was not the only one who liked that idea of "only 
module level encapsulation". Its unfair to imply it like that.
Also, someone may say: I can see what happens in one and the same 
file. If there are two classes/structs in one file, they are 
"friends" and I dont need the "friend"-keyword anymore.

Thats an argument, too.

Re: DConf 2018 Livestream

[meppl via Digitalmars-d-announce]

On Friday, 4 May 2018 at 06:19:13 UTC, meppl wrote:

On Friday, 4 May 2018 at 04:39:16 UTC, Nemanja Boric wrote:
On Friday, 4 May 2018 at 00:09:53 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 05/03/2018 11:12 AM, Nemanja Boric wrote:

[...]


It's working for me:
https://www.youtube.com/watch?v=0UZuRNujLGQ

Maybe youtube just needed some time after the original stream 
ended before it could do replays of the whole thing.


Looks like it, it works for me now as well!

This looks like to be the first day (or recorded part of it): 
https://www.youtube.com/watch?v=HvqsUO77FGI


The second day (from your post): 
https://www.youtube.com/watch?v=0UZuRNujLGQ




no, its the other way around. also, "walter bright"-talk and 
some other are still missing


ah, sorry, i was confused. the order is right. but some 
presentations are really missing/lost

Re: DConf 2018 Livestream

[meppl via Digitalmars-d-announce]

On Friday, 4 May 2018 at 04:39:16 UTC, Nemanja Boric wrote:
On Friday, 4 May 2018 at 00:09:53 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 05/03/2018 11:12 AM, Nemanja Boric wrote:

On Thursday, 3 May 2018 at 12:24:16 UTC, Per Nordlöw wrote:

[...]


It looks like you can just watch inside last two hours window.


It's working for me:
https://www.youtube.com/watch?v=0UZuRNujLGQ

Maybe youtube just needed some time after the original stream 
ended before it could do replays of the whole thing.


Looks like it, it works for me now as well!

This looks like to be the first day (or recorded part of it): 
https://www.youtube.com/watch?v=HvqsUO77FGI


The second day (from your post): 
https://www.youtube.com/watch?v=0UZuRNujLGQ




no, its the other way around. also, "walter bright"-talk and some 
other are still missing

Re: LDC 1.9.0 beta

[meppl via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 15:53:23 UTC, Joakim wrote:

On Monday, 23 April 2018 at 09:18:07 UTC, Suliman wrote:
What about Webassembly support? Latest LLVM suppport it, so 
LDC should support also.


We don't support a lot of platforms that llvm supports. It will 
require someone to work on the port, which hasn't happened. 
I've said before that I don't think it's worth it, because the 
web has been declining as a platform:


https://forum.dlang.org/post/unqvdzopebfksnxwh...@forum.dlang.org



I stumbled over this:
http://blog.qt.io/blog/2018/04/23/beta-qt-webassembly-technology-preview/
https://sdtimes.com/webdev/mozillas-webassembly-studio-enters-beta/

I dont want to argue, just throwing that in ;)

Re: that is bug?

[meppl via Digitalmars-d]

On Saturday, 7 April 2018 at 10:25:19 UTC, bauss wrote:

On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:


true?stt="AA":stt="BB";-///Out:BB


It's an UB.

Not a bug.



I want `condition ? expr1 : expr2` to behave like:

-
auto qc( alias condition, string expr1, string expr2)() {
if( condition) {
return mixin( expr1);
} else {
return mixin( expr2);
}
}
-

Re: Beta 2.079.0

[meppl via Digitalmars-d-announce]

On Saturday, 31 March 2018 at 00:25:47 UTC, Seb wrote:
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak 
wrote:

On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:

[...]


No need to use it if you don't like it. It's particularly 
useful for small examples, localized imports and hacking.
It's mainly a generalisation of the existing possibility to 
mix module imports and one selective import at the end.
If you prefer java-like 50 lines import manifests, then by all 
means keep using those.

How would that feature cause bugs though?


AFAICT Rust now has introduced the exactly same feature. It's 
quite interesting to see that there was no outcry by the 
community and it was universally liked:


https://blog.rust-lang.org/2018/03/29/Rust-1.25.html
https://github.com/rust-lang/rust/issues/44494


the curly brackets make the rust implementation more readable. 
The dmd implementation didn't use brackets. I believe that's a 
main reason for the resistance from the people

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[meppl via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 04:46:21 UTC, meppl wrote:

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

...


Sometimes I want to use a debugger like gdc. If it works, it 
can be really useful. I skipped trying out Nim, because 
debugging was not really supported. I wonder, if this is fixed 
now


I wanted to write "gdb" of course.
There is an article about debugging nim:
https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[meppl via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast


Sometimes I want to use a debugger like gdc. If it works, it can 
be really useful. I skipped trying out Nim, because debugging was 
not really supported. I wonder, if this is fixed now

Re: State of D 2018 Survey

[meppl via Digitalmars-d-announce]

On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote:


https://seb134.typeform.com/to/H1GTak



I might have overseen it, but in the survey I missed the feature 
"being able to allocate withing @nogc-CTFE-functions". Some 
people want to promote a @nogc library and they cant use CTFE to 
the full extend then.

( see also: https://issues.dlang.org/show_bug.cgi?id=18119 )

Re: Equivalent to Python with Statement

[meppl via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 22:00:11 UTC, meppl wrote:

On Wednesday, 28 February 2018 at 21:47:40 UTC, Cym13 wrote:

On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:

[...]


Others have discussed that particular case at length, but to 
provide a more generic answer the correct way to translate a 
python context manager is to use scope(out):


{ // Scope restriction similar to with's block
auto f = File("x.txt");
scope(out) f.close();   // closes f on scope exit no 
matter what


/* do stuff with f */
}

This accurately reproduces the behaviour of python's with 
although it's less automatic.


what is `scope(out)`? I only know these  
file:///usr/share/dmd-doc/html/d/spec/statement.html#ScopeGuardStatement


sorry, my question was not good. I thought there is an 
undocumented feature, never mind ;)

Re: Equivalent to Python with Statement

[meppl via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 21:47:40 UTC, Cym13 wrote:

On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:

[...]


Others have discussed that particular case at length, but to 
provide a more generic answer the correct way to translate a 
python context manager is to use scope(out):


{ // Scope restriction similar to with's block
auto f = File("x.txt");
scope(out) f.close();   // closes f on scope exit no 
matter what


/* do stuff with f */
}

This accurately reproduces the behaviour of python's with 
although it's less automatic.


what is `scope(out)`? I only know these  
file:///usr/share/dmd-doc/html/d/spec/statement.html#ScopeGuardStatement

Re: Beta 2.079.0

[meppl via Digitalmars-d-announce]

On Monday, 19 February 2018 at 23:37:49 UTC, Mike Franklin wrote:

On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:

...



Mike



@"16.": https://dlang.org/changelog/2.079.0.html#minimal_runtime

So, now someone could "easily" write his own memory managment for 
allocations who would be usually done by the default GC - e.g. 
classes?

Re: Return value in BetterC mode.

[meppl via Digitalmars-d-learn]

On Saturday, 17 February 2018 at 13:47:28 UTC, meppl wrote:

On Saturday, 17 February 2018 at 07:58:40 UTC, ANtlord wrote:

...

...
sadly I have no good idea how to name the title of that issue :/


I looked at it again and came up with a title name:


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

Re: Return value in BetterC mode.

[meppl via Digitalmars-d-learn]

On Saturday, 17 February 2018 at 07:58:40 UTC, ANtlord wrote:

Hello!
Yesterday I found an interesting issue for myself while I was 
implementing unique pointer for my project in BetterC. When I 
was trying to return new instance from a `move` method I got 
calling of destructor the instance. When the instance is out of 
scope the calling is happens again. I also see that addresses 
of an instance that calls destructor are same.


That thing doesn't happen when I don't use BetterC mode. Is 
that bug or feature?
Please checkout code https://run.dlang.io/is/m1TRnT and try it 
in BetterC mode and in usual mode.


But if I return result of a constructor directly instead of 
saving the result to variable and returning the variable from 
the `move` method I don't see double calling of the same 
destructor.


I. e.
```
auto newObject = Box(this);
return newObject;
```
is replaced by
```
return Box(this);
```

So... is that bug or feature?


Okay, with the glorious help of the compiler-switch `-vcg-ast` I 
was able to see the source of that weirdness. See also: 
https://forum.dlang.org/thread/juxihybpqpjycmxiy...@forum.dlang.org


It seems that there is always a try-block when the struct has a 
destructor


I reduced your code to:



struct S {
~this() {}
}
S myFunction() {
S s = S();
return s;
}
extern( C) void main(){}




transformation of myFunction() with

$ dmd -betterC -vcg-ast source/app.d

S myFunction()
{
S s = S();
try
{
return s;
}
finally
s.~this();
}


transformation of myFunction() with

$ dmd -vcg-ast source/app.d

S myFunction()
{
S s = S();
try
return s;
catch(Throwable __o3)
{
s.~this();
throw __o3;
}
}



sadly I have no good idea how to name the title of that issue :/

Re: A betterC base

[meppl via Digitalmars-d]

On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote:
On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe 
wrote:
Garbage collection has proved to be a smashing success in the 
industry, providing productivity and memory-safety to 
programmers of all skill levels.


Citation needed on how garbage collection has been a smashing 
success based on its merits rather than the merits of the 
languages that use garbage collection. Python was also a 
smashing success, but it doesn't use a garbage collector in 
it's default implementation (CPython). Unless you mean garbage 
collection as in "not manual memory management"? But that still 
might not be as simple, because RAII would fall somewhere 
inbetween.


let's say python is supposed to offer slow execution. So, python 
doesn't prove reference counting is fast (even if it is possible 
in theory). D on the other hand provides binaries who are 
expected to execute fast.

Re: The ShionKeys project has quietly raised money on indiegogo

[meppl via Digitalmars-d-announce]

On Tuesday, 16 January 2018 at 19:15:52 UTC, artishu wrote:

On Monday, 15 January 2018 at 06:54:04 UTC, ShionKeys wrote:

ShionKeys: I want to change the world
World: You will be alone
... ...
https://igg.me/at/ShionKeys/x/17399884
https://vimeo.



speak more about benefit's:

how long does it take to learn ?
how easy is using it ?
how fast can we type with it ?
etc... (prepare numbers so people be able to compare)

people should feel need this thing...



It doesn't take too long actually. Some weeks at most.
I was using , which is using more layers 
than the common keyboard layouts. but "neo" has a big problem. 
those very free keyboard layouts often don't work, because common 
applications have the power to do the work of the keyboard driver 
(e.g. by binding the "alt"-key to the common usage).
Thus, i am interested in a solution who just works. Maybe writing 
a new hackish keyboard usb driver who is replacing the key codes 
before any other software becomes into play  would solve the 
problem.

Re: Adding Markdown to Ddoc

[meppl via Digitalmars-d]

On Tuesday, 12 December 2017 at 13:50:42 UTC, Bastiaan Veelo 
wrote:

On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis 
wrote:


And then you have to worry about something like int* screwing 
with things, because the compiler decides that you wanted 
italics. Honestly, I don't think that something like $(I foo) 
is very onerous - it's not all that different from foo 
or [i]foo[/i] (which plenty of folks are familiar with), but 
it's shorter and less visually noisy - and it doesn't risk 
having stuff that isn't supposed to be markdown being treated 
as markdown.


[...]


Try this one (paste it into 
http://spec.commonmark.org/dingus/):


# CommonMark

```
int* ptr;
```
`int*` is a pointer to an integer.

int* is a pointer to an integer.


Coming up with a counter example is easy. Try this:

To dereference a pointer variable, write *i. To define a 
pointer variable, write int* i.


Inserting backticks obviously solves this and personally I 
would be fine with that requirement, but Markdown is not 
completely harmless. The above line comes out totally as not 
intended.


speaking of "harm". I would say there is not much harm when the 
API-docs are broken at a certain place. Furthermore it is never 
super difficult to fix. In comparison: Bugs in a programming 
language are from a different world and super much more harmful 
up to 9000.

Re: Adding Markdown to Ddoc

[meppl via Digitalmars-d]

On Tuesday, 12 December 2017 at 06:55:45 UTC, Jonathan M Davis 
wrote:
On Tuesday, December 05, 2017 20:11:33 Walter Bright via 
Digitalmars-d wrote:

https://help.github.com/articles/basic-writing-and-formatting-syntax/

Anyone interested in picking up the flag?

(I know this has come up before, and I've been opposed to it, 
but I've

changed my mind.)


I confess that looking over that page, I don't see much reason 
to add any of it to ddoc. It all seems like stuff that we can 
already trivially do in ddoc, and most (all?) of it is stuff 
that already has built-in macros. What are we really trying to 
gain here?




1) I avoid writing something like $(I foo) into a comment. 
Because other people may actually read my source code and not 
just read a generated documentation from a source code. So, I 
would prefer writing *foo* or _foo_. After all that's the point 
of markdown: Pure text _looks_ like intended and enables 
html-generation at the same time.


2) If someone learns the D programming language, I think it would 
be advantageous, if that person could just write down the already 
known markdown grammar

Re: Adding Markdown to Ddoc

[meppl via Digitalmars-d]

On Sunday, 10 December 2017 at 06:20:43 UTC, Walter Bright wrote:

On 12/9/2017 9:17 PM, meppl wrote:
since commonmark exists, is specified and is compatibale to 
many markdown-languages,  I claim there is a markdown 
standard: http://spec.commonmark.org/


It certainly wants to be the standard, but until most everyone 
decides to follow it, it is not. There is no list of anyone on 
that site conforming to it.


I think these are wrong criterias to estimate the value of 
commonmark. Commonmark doesn't need to list anyone and doesn't 
need to be listed by anyone to be a standard. commonmark is a 
standard proven by following "facts":
1) whenever a language feature is used by all popular markdown 
languages, it is standard
2) there are markdown features who are used by all popular 
markdown languages
3) everyone can reveal this matter of fact - e.g. by writing it 
down as a specification
4) any language feature published by the commonmark-spec is used 
by all popular markdown languages

ergo: commonmark == standard markdown
well, at least, if the commonmark people did their homework right



Besides, commonmark has a lot of stuff we don't need, like 
multiple ways of doing the same thing.


I am not the one who is implementing it, so I will not argue 
against this.

Re: Adding Markdown to Ddoc

[meppl via Digitalmars-d]

On Sunday, 10 December 2017 at 01:19:13 UTC, Walter Bright wrote:

On 12/9/2017 12:23 PM, Jacob Carlborg wrote:

On 2017-12-09 02:49, Walter Bright wrote:

This is way overstating the case. Ddoc already supports some 
markdown, and some markdown in different ways.


Yes, but I haven't yet seen any official documentation saying 
that Ddoc supports Markdown syntax.


There isn't any, because officially saying Markdown is 
supported is too vague. There is no Markdown standard.


But what Ddoc does do should be officially documented, and is 
as far as I know.


since commonmark exists, is specified and is compatibale to many 
markdown-languages,  I claim there is a markdown standard:  
http://spec.commonmark.org/


commonmark is the common denominator of the markdown-languages.

Re: @ctfeonly

[meppl via Digitalmars-d]

On Thursday, 7 December 2017 at 03:43:42 UTC, Nicholas Wilson 
wrote:

...

Do you have any other ideas about how to achieve this other 
than an attribute?

Having an attribute seems the most simple and straightforward.


llvm has "Aggressive Dead Code Elimination"- and "Dead Code 
Elimination"-switches, who I find interesting.

https://llvm.org/docs/Passes.html#transform-passes

I remember once I actually stripped off kinda 99% of a statically 
linked phobos-library with that and I got a small executable who 
was still working

Re: Project Elvis

[meppl via Digitalmars-d]

On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:

On 11/6/17 12:20, Michael wrote:
I can't quite see why this proposal is such a big deal to 
people - as
has been restated, it's just a quick change in the parser for 
a slight
contraction in the code, and nothing language-breaking, it's 
not a big

change to the language at all.

On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
I am all for the Elvis operator, however I have two 
reservations about

it. The first is that I don't see much use for it without a
null-conditional. The second is that the current proposed 
syntax ?: is

MUCH to easily confused with ?.

This is not easy to read: obj1?.obj2?.prop3?:constant.

When designing syntax sugar, ergonomics are very important, 
otherwise
people won't use it. Microsoft spent a LOT of time and 
treasure to
learn these lessons for us. I see no reason to ignore them 
just

because "we don't like Microsoft"

My proposal would be to copy what MSFT did, expect that I 
would I

would introduce both operators at the same time.

Syntax as follows: obj1?.obj2?.prop3 ?? constant

In practice I don't see much use of the idiom outside of 
null's. The
ONLY other thing that would work there is a boolean field and 
you
might as well just return the boolean itself because the 
return values

have to match types.


I feel this is kind of embellished somewhat. When you write


This is not easy to read: obj1?.obj2?.prop3?:constant.


you're not separating it out as you do when you write your 
preferred

version:


Syntax as follows: obj1?.obj2?.prop3 ?? constant


How is


obj1?.obj2?.prop3 ?: constant


not as easy to read as



obj1?.obj2?.prop3 ?? constant




You're right, I didn't, that was intentional, because sometimes 
people write things like that. And it took a while for anyone 
to say anything about it. That is my point.


But that's the thing. The ?? is significantly more obvious in 
the condensed version.


This is something that a UX designer would recognize instantly, 
but human factors are very definitely not our strong skill as 
engineers. FWIW, my human factors experience comes from the 
deep study of airline crashes that I do as a pilot.


to me they are the same in terms of readability, only with ?? 
you have
greater chances of mistyping and adding a second ? in there 
somewhere,
whereas the ?: is just a contraction of the current syntax, I 
really
don't think it's that difficult, so I'm not sure what people's 
hang-ups
are, but I don't think the argument that ?? is easier to read 
than ?:
holds any weight here, because one *is* a change to the 
language, and
the other is a change to the parser and a contraction of a 
standard

convention.



Two things. ?: is ALSO a change a to language (lexer+parser). 
As to the whole "it's no more likely to typo the colon than the 
question" argument, sure, but that depends on the keyboard 
layout more than anything else, what works for you may not work 
elsewhere. And in either case, it's an easy compiler error. So 
you don't win anything with the ?:, but you win readability 
with the ??. MSFT spends a LOT of time studying these things. 
It would be wise to learn for free from the money they spent.


I still dont get your point. Are you sure `??` isn't more 
readable for you, because you are just used to it?


I think `?:` makes more sense to me and people who learn the D 
programming language.
At least As log as `null` becomes `false` and non-null-pointer 
becomes `true`.


If the operator shall check for `null` only, I would be fine with 
`??`.
Because then it wouldn't be a true shortcut of  
https://dlang.org/spec/expression.html#ConditionalExpression  
anymore


I wonder what Mr. Bright and Mr. Alexandrescu would say about the 
request to implement both, `??` and `?:`.

Re: My two cents

[meppl via Digitalmars-d]

On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

conditional dereferencing and stuff about that (same as in C#)
...

...

implement this thing from C# (just because it's cool)
new Foo() {
  property1 = 42,
  property2 = "bar"
};



Thanks for your time.
- Satoshi


I really wish this was implemented for classes too! Currently 
it exist for structs and it completely baffles me why it has 
never been implemented for structs.


maybe because of open questions. what is with private variables 
in a class?


At the current time i can set private variables in a D-struct 
from a different module:


// in amod.d

struct S
{
private:
immutable   int a = 33;
}


// in bmod.d

S x = { a:1}; // no error
auto y = S( 1); // no error

the D-documentation doesnt tell, if this is valid behaviour of 
the compiler, whatever, for now I just assume it is.


maybe it is not a good thing to be able to do that. but at the 
same time the user should decide at object initialization what 
value _some_ private variables shall have. so, that's what the 
constructor usually is good for, too. let the user set only 
certain private variables one time at initialization. with the 
amod.d-code above there is no way to disallow resetting all 
private variables.


And: If i can only set public variables, it is not a perfect 
solution either

Re: My two cents

[meppl via Digitalmars-d]

On Sunday, 22 October 2017 at 15:07:10 UTC, meppl wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:


syntactic sugar for:
tuples


as far as i know there was the will to implement tuples in the 
language, but there is still a deprecation in the way:

https://dlang.org/deprecate.html#Using%20the%20result%20of%20a%20comma%20expression


oh, i was wrong. after testing it i noticed "Using the result of 
a comma expression" doesnt work anymore.

Re: My two cents

[meppl via Digitalmars-d]

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:


syntactic sugar for:
tuples


as far as i know there was the will to implement tuples in the 
language, but there is still a deprecation in the way:

https://dlang.org/deprecate.html#Using%20the%20result%20of%20a%20comma%20expression

Re: My two cents

[meppl via Digitalmars-d]

On Sunday, 22 October 2017 at 01:02:06 UTC, EntangledQuanta wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

...


These guys are old now and don't have the drive they used to 
have. It happens, part of life. Unfortunately they do not 
realize this and do not want to pass the torch. I wouldn't 
expect anything major for D any more unless something 
significant changes in the management.


I thought the actual problem is just that dlang has not enough 
developer resources. Being young doesn't fix that. Wasn't the 
staff old already when D2 came out?


ps, also i want something similar to this in D:

new Foo() {
  property1 = 42,
  property2 = "bar"
};
it might solve things better than named parameters  
https://wiki.dlang.org/DIP88

Re: Current limitations of -dip1000

[meppl via Digitalmars-d]

On Tuesday, 10 October 2017 at 09:55:13 UTC, meppl wrote:

...


also, these differ:
(with dmd v2.076.0)

@safe:
struct S {
@safe:
int* x;
scope int* pointer() return {
return x;
}
}
int* testPointer() {
S s;
return s.pointer(); // no error
}
struct SA {
@safe:
int[ 128] x;
scope int* pointer() return {
return [ 0];
}
}
int* testPointerA() {
SA s;
return s.pointer(); // error
}

Re: Current limitations of -dip1000

[meppl via Digitalmars-d]

On Tuesday, 10 October 2017 at 02:37:21 UTC, Walter Bright wrote:

On 10/9/2017 8:04 AM, Per Nordlöw wrote:

...


Get rid of the templates, too. Replace T with int. Get rid of 
any of the layers of confusing complexity.

...


this looks like an issue to me. If its a template the pointer can 
escape. The non-template-version doesnt let the pointer escape


@safe:
struct ST( T) {
@safe:
T[ 128] x;
scope ref T front() return {
return x[ 0];
}
scope T* pointer() return {
return [ 0];
}
}
ref int testFrontT() {
ST!int s;
return s.front(); // pointer escapes
}
int* testPointerT() {
ST!int s;
return s.pointer(); // pointer escapes
}

struct S {
@safe:
int[ 128] x;
scope ref int front() return {
return x[ 0];
}
scope int* pointer() return {
return [ 0];
}
}
ref int testFront() {
S s;
return s.front(); // error
}
int* testPointer() {
S s;
return s.pointer(); // error
}

Re: dlang.org faq says dmd is licensed with norton license

[meppl via Digitalmars-d]

On Tuesday, 29 August 2017 at 06:56:13 UTC, Jonathan M Davis 
wrote:
On Tuesday, August 29, 2017 06:43:19 meppl via Digitalmars-d 
wrote:

...
Both the frontend and backend are now entirely under the Boost 
license. ...

okay, PR was sent

dlang.org faq says dmd is licensed with norton license

[meppl via Digitalmars-d]

i incidentally noticed the FAQ claims the dmd-backend would be 
licensed under a norton license. i thought it is an outdated 
information:

https://dlang.org/faq.html#q5


however, i also checked the source code and it turned out that 
some files dont contain the string "boost":

$ fgrep -iLR boost src/ddmd/backend/
src/ddmd/backend/bcomplex.h
src/ddmd/backend/dt.h
src/ddmd/backend/backend.txt
src/ddmd/backend/code_stub.h
src/ddmd/backend/dwarf2.h
src/ddmd/backend/dwarf.d
src/ddmd/backend/mach.d
src/ddmd/backend/md5.c
src/ddmd/backend/md5.h
src/ddmd/backend/bcomplex.c
src/ddmd/backend/mscoff.d
src/ddmd/backend/dwarf2.d
src/ddmd/backend/xmm.h
src/ddmd/backend/cv4.d
src/ddmd/backend/mscoff.h
src/ddmd/backend/mach.h
src/ddmd/backend/dwarf.h
src/ddmd/backend/melf.h
src/ddmd/backend/md5.d
src/ddmd/backend/bcomplex.d
src/ddmd/backend/cv4.h


do you think the missing license headers are relevant? If not, i 
would make a pull request for the FAQ

Re: DMD license question

[meppl via Digitalmars-d]

...


okay, the actual problem is i create libraries multiple times. i 
think dub doesnt allow me to explicitly build the 
depency-libraries as shared libraries (to avoid the 
multiplication). then maybe an alternate build system would make 
it possible. however, i wont employ this for now.

Re: DMD license question

[meppl via Digitalmars-d]

On Monday, 7 August 2017 at 21:28:52 UTC, Andre Pany wrote:

Hi,

as DMD is now under Boost Software License, can I distribute it 
as part of my commercial product?


I want to provide script support within my application. The 
idea is to compile the scripts (D coding) to shared libraries 
and load the shared libraries into the main program.


Kind regards
André


in case your main application is written in D, too:  how do you 
avoid symbol name collisions?


I think it would be nice to load shared libraries while runtime, 
but i cant, because the symbol names of the imports get 
duplicated which is not allowed. And D intentionally has no 
namespace-feature for this

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[meppl via Digitalmars-d]

On Wednesday, 21 June 2017 at 12:05:55 UTC, Moritz Maxeiner wrote:

On Wednesday, 21 June 2017 at 09:53:40 UTC, meppl wrote:

On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner 
wrote:

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0) { ... }


avoiding the "anonymous scope"-extra wouldnt hurt much?

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0)
  do { ... }


Adding `if (...)` should not be different from adding `in 
(...)` or `out (...)` in terms of syntax rules: it's 
inconsistent. If you want to have that `do` there, I would 
argue that it should also become required if only an `if (...)` 
is present, so


---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   { ... }
---

should then become illegal and must be rewritten as

---
 int myFunc(Args...)(Args args)
   if (Args.length > 2)
   do { ... }
---

I doubt that's going to happen, though (too much code 
breakage), and I also don't like it. Simply drop the `do`.



yeah, i was probably not thinking too carefully about it. My idea 
was to keep the code readable, if the contracts are long. but as 
long as the "do" must appear behind a '}', everything is still 
fine, more or less.



int myFunc1(Args...)(Args args)
if (Args.length > 2)
in
{
// much code
}
do
{
...
}


int myFunc2(Args...)(Args args)
if (Args.length > 2)
in
{
// much code
}
out (result => result > 0)
{
...
}


both are readable, but one time we write `do` and the other time 
we dont. furthermore the second function body looks a little bit 
like belonging to "out". someone who is learning the D-language 
might get confused.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[meppl via Digitalmars-d]

On Wednesday, 21 June 2017 at 09:27:20 UTC, MysticZach wrote:

On Wednesday, 21 June 2017 at 08:15:34 UTC, MysticZach wrote:
On Wednesday, 21 June 2017 at 04:16:22 UTC, Moritz Maxeiner 
wrote:

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0) { ... }


avoiding the "anonymous scope"-extra wouldnt hurt much?

int myFunc(Args...)(Args args)
  if (Args.length > 2)
  in (args[0] != 0)
  in (args[1] > 1)
  out (result => result > 0)
  do { ... }

Re: Replacing Make for the DMD build

[meppl via Digitalmars-d]

On Monday, 19 June 2017 at 09:19:32 UTC, Dejan Lekic wrote:

On Friday, 16 June 2017 at 06:30:01 UTC, Russel Winder wrote:

A direct question to Walter and Andrei really.

If someone, let us say Russel Winder, create a CMake/Ninja 
and/or Meson/Ninja build for DMD, is there any chance of it 
being allowed to replace the Make system?


If the answer is no, then Russel will obviously not waste his 
time doing something that will not be accepted.


Why?

Why replacing a rock-stable Make with build-system-X that most 
likely adds another dependency. I am with Walter on this one. - 
We should continue using Make unless there is a real need for 
something else. DMD's makefiles are really simple!


is there a point in disallowing several alternate build systems 
residing in the dmd repository?
If it is just allowed to upload README-files and make-files of 
alternate build systems etc, it would not be necessary to waste 
time with this discussion here.

Re: Creating a dub library package that also comes with an executable

[meppl via Digitalmars-d]

On Sunday, 18 June 2017 at 16:51:41 UTC, Martin Nowak wrote:

Might be interesting for more people.

Just added a recipe to our dub cookbook (yes that exists).


would be nice to make that Wiki ( 
https://github.com/dlang/dub/wiki ) more visible to people who 
visit http://code.dlang.org/

Re: D needs to get its shit together!

[meppl via Digitalmars-d]

On Sunday, 18 June 2017 at 14:53:57 UTC, Wulfklaue wrote:
But it really comes down in its most simple form: "Language 
good, library can use some work but useful, standard 
documentation disaster ( until you discover the library doc ),


some people keep saying that. and i dont understand them. i think 
the documentation of the d language is good. i could learn the 
whole language with just looking at 
http://dlang.org/spec/spec.html
It contains many examples and is easy to read. Someone 
exclusively coming from the scripting-world  might have issues 
though, i am not sure

Re: Isn't it about time for D3?

[meppl via Digitalmars-d]

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I realize that there are people who want to continue using D as 
it is, but those people may continue to use D2. Putting the 
breaking changes in a separate branch ensures that DM won't 
lose current clients as they can just continue using D2 as they 
are. Even after D3 is stabilized, D2 could have continued 
support until nobody wants it.




sorry, i was overreading those lines of yours

Re: Isn't it about time for D3?

[meppl via Digitalmars-d]

in my opinion starting with D3 is too early, because D-people 
dont even seem to know how exactly to implement new exciting 
features like "reference counting" (and how will "reference 
counting" work together with the new "scope"-feature?).


So, if a D3 gets developed _now_, i guess the compiler developers 
will create syntax issues again for those features and then we 
need a D4. Instead it might be better to collect more experience 
before thinking about D3

Re: Rename 'D' to 'D++'

[meppl via Digitalmars-d]

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should at 
least be honest with themselves.


look here:  
https://en.wikipedia.org/wiki/C_(programming_language)#History


so, once upon a day there was _A_ssembler. then a language of the 
name "B" was created. later a successor language was created - 
called "C".


it happened that someone was not satisfied with "C", but didnt 
really want to abandon "C". thats why he created a superset of 
"C" and called it "C++".  a "C" with more capabilities.  (thats 
probably not 100% true, but still pretty much the meaning of the 
name).


another person was not satisfied and created another successor. 
"D" was born. "D" abandoned compatibility with "C" - more than 
"C++" did. also, "D" is ment to be a successor of C/C++. but "D" 
is not a (C++)++ or C+2, also not a C++, because its not a 
superset, since it breaks compatibility to the predecessors


in that context, i think the name is _not misleading_:  A B C C++ 
_D_

Re: DIP 1003: remove `body` as a keyword

[meppl via Digitalmars-d-announce]

Indentation syntax

If we have an optional indentation syntax one day, those 
anonymous looking scopes behind functions may become weird things.


int div(int a, int b)
in { assert(b != 0); }
{
return a / b;
}

indentation:

int div( int a, int b)
in:
assert( b != 0)
:
return a / b



And i like two proposals of this thread here who are not part of 
the DIP:



Kagamin's proposal to just use a shorter keyword than "body" or 
"function".



int div(int a, int b)
in { assert(b != 0); }
do
{
return a / b;
}



Sönke Ludwigs suggestion:

Really nice would be if "in" and "out" would then also take a 
general statement instead of just a block statement, so that a 
syntax like this would become possible for simple contracts:


void foo(int a, int b)
  in assert(0 <= a && a < b);
  out(ret) assert(ret < b);
{
  return b - 1 - a;
}

Re: Beta release DUB 1.0.0-beta.1

[meppl via Digitalmars-d-announce]

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:


#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/



this is exactly what i could make good use of for my scripting 
stuff. thank you for implementing