Re: DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

https://github.com/dlang/DIPs/pull/63

Re: DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

On Thursday, 11 May 2017 at 17:35:31 UTC, Nick Sabalausky 
(Abscissa) wrote:
It is already addressed in the DIP. FQNs only help if they are 
used and
current idiomatic D code tends to rely on unqualified 
imports/names.




I didn't see that. Certainly not in the "Existing solutions" 
section. It needs to be there.


It is mostly discussed in "Comparison with other languages" 
section - it is not a solution for the DIP problem, it is one of 
problems the DIP tries to solve. You put it kind of backwards in 
my opinion.


Only if you consider "after compiler/library upgrade your 
project
doesn't work anymore" a sufficient "informing" which we 
definitely don't.


I definitely do. But even if you don't, see my "@new_func" 
alternate suggestion.


This suggestion seems considerably more complex - it requires 
either additional tools to specify "yes, I truly want to use that 
new function" or forcing developer to always use FQN to do it. 
Required compiler changes are likely to be more convoluted too 
because same symbols would have to be interpreted as regular of 
"fake" ones depending on the context.


Most importantly, I don't see motivation behind it. For 
conservatively maintained libraries defining no-op stub one 
version before introducing actual implementation is hardly a 
problem. Everyone else won't bother about it at all and just add 
new symbols in a regular manner.


Trivial compilation error fixup that takes 5 minutes to 
address in a
single project takes up to one month to propagate across all 
our
libraries in projects per my experience. Actually fixing code 
is hardly
a problem with breaking changes, ever. It is synchronization 
between

developers and projects that makes it so painful.



This needs to go in the DIP.


No, it does not.

That paragraph is a generic rationale why _any_ breaking changes 
without deprecation paths are so painful. I have no interest in 
trying to convince anyone who doesn't get it by now.



And in override case, there is no backwards compatible solution
available at all (see Steven comment).


This needs to be made explicit in the DIP. Currently, I see 
nothing in the DIP clarifying that FQNs cannot address the 
override case.


Yeah, will do.

Re: DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

On Thursday, 11 May 2017 at 03:46:55 UTC, Nick Sabalausky 
(Abscissa) wrote:
1. Why are FQNs alone (assume they still worked like they're 
supposed to) not good enough? Needs to be addressed in DIP. 
Currently isn't.


It is already addressed in the DIP. FQNs only help if they are 
used and current idiomatic D code tends to rely on unqualified 
imports/names.


2. The library user is already going to be informed they need 
to fix an ambiguity anyway, with or without this DIP.


Only if you consider "after compiler/library upgrade your project 
doesn't work anymore" a sufficient "informing" which we 
definitely don't.


3. Updating code to fix the ambiguity introduced by a new 
symbol is always trivial (or would be if FQNs were still 
working properly and hadn't become needlessly broken) and 
inherently backwards-compatible with the previous version of 
the lib.


Trivial compilation error fixup that takes 5 minutes to address 
in a single project takes up to one month to propagate across all 
our libraries in projects per my experience. Actually fixing code 
is hardly a problem with breaking changes, ever. It is 
synchronization between developers and projects that makes it so 
painful.


And in override case, there is no backwards compatible solution 
available at all (see Steven comment).



Unlike when symbols being added to a lib, the fix in user-code 
for a deprecation *can* be non-trivial and *can* be 
non-backwards-compatible with the previous version of the lib, 
depending on the exact circumstances. Therefore, unlike added 
symbols, the "deprecation" feature for removed symbols is 
justified.


Please elaborate. User code fix is always either using FQN or 
renaming, what non-trivial case comes to your mind?


4. Unlike deprecation, this feature works contrary to the 
actual flow of development and basic predictability:


When a lib author wants to remove a symbol, they already what 
the symbol is, what it's named and that they have X or Y reason 
to remove it. But when a lib author wants to add a symbol, it's 
more speculative: They don't actually KNOW such details until 
some feature is actually written, implemented and just about 
ready for release. At which point it's a bit late, and awkward, 
to go putting in a "foo *will* be added".


You describe a typical library that doesn't follow SemVer and 
generally doesn't bother much about providing any upgrade 
stability. Naturally, such library developer will ignore 
`@future` completely and keep following same development patterns.


Not everyone is like that though. This document 
(https://github.com/sociomantic-tsunami/neptune/blob/master/doc/library-maintainer.rst) explains the versioning/development model we use for all D libraries and within such model feature that is written in one major version can be added as `@future` in the previous major version at the same time.


And for druntime object.d case it is pretty much always worth the 
gain to delay merging already implemented addition for one 
release, putting `@future` stub in the one before. There can 
never be any hurry so there is no way to be "late".

Re: DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

On Thursday, 11 May 2017 at 00:04:52 UTC, Steven Schveighoffer 
wrote:
I prefer the first one. The reason is simply because it doesn't 
require any new grammar. The override requirement is already a 
protection against changing base class. In this case, we have 
two possible outcomes:


1. The base class finally implements the method and removes 
future. In this case, the derived class continues to function 
as expected, overriding the new function.


2. The base class removes the method. In this case, the 
override now fails to compile. This is not as ideal, as this 
does not result in a version that will compile with two 
consecutive versions of the base. But there is a possible path 
for this too -- mark it as @deprecated @future :)


-Steve


Sounds reasonable. I'll submit an update to the DIP.

Re: DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer 
wrote:
Actually, that brings up a problem with this, what is the 
mechanism to say "maybe override"? Let's say you have:


// in imported library
class Base
{
   void foo() @future;
}

// in user library
class Derived : Base
{
   void foo() {...} // triggers warning
}

What is the next step the user has to take to remove the 
deprecation warning, but still have valid code?


Right now I have two possible approaches in mind.

One is to simply allow overriding `@future` symbol which doesn't 
require any extra stuff but can be viewed sub-optimal because it 
couples two loosely related concepts and would require special 
cases in how future symbols are handled inside compiler (they 
stop being completely ephemeral).


Other would be an accompanying DIP to be able to specify 
`overide(strict)` (default, same as plain `override`) vs 
`override(optional)` to be able to define methods that may or may 
not override base one, with no specific relation to `@future`.


I don't have any hard opinion on the matter of my own, what do 
you think?

Re: D for scripting?

[Dicebot via Digitalmars-d]

On Sunday, 22 January 2017 at 12:45:26 UTC, Russel Winder wrote:
The "problem" here is the role of the D Tools repository. Is it 
solely for DMD, or is it supposed to be something that can be 
packaged independent of a particular D compiler. As it is I am 
not sure it can be the unit of packaging.


Some time ago I have been packaging tools from that repo build 
with LDC in Arch Linux, it is trivially doable (see 
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dtools#n26).

Re: D for scripting?

[Dicebot via Digitalmars-d]

On Sunday, 22 January 2017 at 13:24:48 UTC, Andrei Alexandrescu 
wrote:
It's also the simplest to solve. Should be Boost. Please create 
a PR copying the Boost license (from e.g. Phobos itself) to the 
tools repo. Thanks. -- Andrei


RDMD does have license statement already 
https://github.com/dlang/tools/blob/master/rdmd.d#L9-L11

Re: Catching Errors

[Dicebot via Digitalmars-d]

On 01/20/2017 07:47 AM, Jacob Carlborg wrote:
> On 2017-01-19 16:46, Jack Stouffer wrote:
> 
>> Or, you can mark that unit test block as @system and have @safe tests in
>> another block.
> 
> No, this is for when the framework is catching the exception. It needs
> to wrap _all_ unit test blocks in a try-catch. If an assert fails I want
> the rest of the unit tests to be able to run.

And if one is to take language spec by heart, currently ANY framework
that implements it relies on undefined behavior :(

Usage of `assert` in unittests was quite a mistake.




signature.asc
Description: OpenPGP digital signature

Re: Lets talk about fibers

[Dicebot via Digitalmars-d]

On Sunday, 8 January 2017 at 09:18:19 UTC, Suliman wrote:
Simply picking a worker thread + worker fiber when task is 
assigned and sticking to it until finished should work good 
enough. It is also important to note though that "fiber" is 
not the same as "task". Former is execution context primitive, 
latter is scheduling abstraction. In fact, heavy load systems 
are likely to have many more tasks than fibers at certain 
spike points.


Could you explain difference between fibers and tasks. I read a 
lot, but still can't understand the difference.


Fiber is context switching primitive very similar to thread. It 
is different from thread in a sense that it is completely 
invisible to operating system and only does context switching 
when explicitly told so in code. But it still can execute 
arbitrary code. When we talk about fibers in D, we usually mean 
https://dlang.org/library/core/thread/fiber.html


Task is abstraction over some specific piece of work to do. Most 
simple task one can think of is simply a function to execute. 
Other details may vary a lot -different languages and libraries 
implement tasks differently, and D standard library doesn't 
define it all. Most widespread task definition in D comes from 
vibe.d - http://vibed.org/api/vibe.core.task/Task


To summarize - fiber defines HOW to execute code but doesn't care 
which code to execute. Task defines WHAT code to execute but 
normally has no assumptions over how exactly it gets run.

Re: ModuleInfo, factories, and unittesting

[Dicebot via Digitalmars-d]

On 12/20/2016 10:36 PM, Walter Bright wrote:
> On 12/20/2016 11:05 AM, Dicebot wrote:
>> Yes, pretty much. What ways do you have in mind? I am only aware of two:
>>
>> 1) ModuleInfo
>> 2) https://dlang.org/spec/traits.html#getUnitTests
> 
> 
> Put pointers to them in a special segment.

Oh, so you have meant "other ways can be implemented", not "other ways
exist"? Sure. It does need to include qualified module names in that
info though to preserve existing test runner functionality.



signature.asc
Description: OpenPGP digital signature

Re: ModuleInfo, factories, and unittesting

[Dicebot via Digitalmars-d]

On 12/20/2016 08:33 PM, Walter Bright wrote:
> On 12/20/2016 12:01 AM, Dicebot wrote:
>> We rely on ModuleInfo for custom test runner in ocean
>> (https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/core/UnitTestRunner.d).
>>
>> Static introspection can't provide same functionality in general case
>> (even if all bugs will be fixed) because it requires either maintaining
>> list of all modules or ensuring everything is imported from some root
>> module. Former is inconvenience, latter is simply not true for libraries
>> (though can be worked around by build system).
> 
> Does that simply need to find all the unit tests? (There are ways to do
> that without ModuleInfo, it's just that it's convenient and portable
> with ModuleInfo.)

Yes, pretty much. What ways do you have in mind? I am only aware of two:

1) ModuleInfo
2) https://dlang.org/spec/traits.html#getUnitTests



signature.asc
Description: OpenPGP digital signature

Re: D future ...

[Dicebot via Digitalmars-d]

On 12/20/2016 05:17 PM, Benjiro wrote:
> On Tuesday, 20 December 2016 at 14:09:45 UTC, Dibyendu Majumdar wrote:
>>
>> Apologies for being one of those who offers advice but no action.
> 
> Don't be Dibyendu ...
> 
> We "ranters" are actually D's "client base". There seem to be the wrong
> impression by the D-Team, that the "clients" are also the people who
> need to help grow D.

Just how much exactly are paying to D Foundation for support to call
yourself a client? What are your support contract terms?

> I do not recall seeing on the C++ and other forums this constant
> attitude from fix it yourselves or put it in the libraries or ... Its
> mostly on the smaller languages where they lack people. And at the same
> time, that is a very scary though for companies who want to use a language.

Yes, D is small language with no developers and no funds and C++ is huge
one with enormous corporate involvement, enough to afford big crowd of
free riders. Your point?

> Anyway, enough "ranting" for me, back to work.

I am really tired of this recurring bullshit of random guys coming up
and acting as if they have any right to demand anything. You distract
those few that are willing to do the work from focusing on it, you are
not capable of saying anything not widely known and you have no desire
to contribute yourself.

My opinion? Fuck off.



signature.asc
Description: OpenPGP digital signature

Re: D future ...

[Dicebot via Digitalmars-d]

On 12/20/2016 12:48 PM, Benjiro wrote:
> Actually, i did not vent any anger until this morning when i noticed the
> wiseass response. All the points i wrote yesterday are items that
> actually bother a lot more people. But those same people who complain
> about it, always get shutdown with that typical: Do it yourself response
> / Improve the standard library / ...

Can you list specific list of actions/events you would have wanted to
see as a result of your post? Literally "person X does Y". Trying to
write it down is very likely to make obvious why no other reaction than
one you have got is possible.



signature.asc
Description: OpenPGP digital signature

Re: A betterC modular standard library?

[Dicebot via Digitalmars-d]

On 12/18/2016 11:26 AM, Ilya Yaroshenko wrote:
> Hi,
> 
> Who is interested in betterC _modular_* standard library?
> I am planing to make libmir org a community for it.
> Thought and concerns?

I also consider Phobos a lost cause only suitable for scripting
purposes. However what you try to do won't be acceptable for me either
(see below).

> We already have better `cpuid` and better `random` packages. The betterC
> std.range and std.algorithm analogs would be released with new ndslice
> implementation. Mir's algorithm would be faster then Phobos and will
> generate less template bloat. Then lightweight threads, multithread
> GLAS, matrix inversion. Fastest I/O and http2 ...

I consider only algorithms and interfaces suitable for standard library.
GLAS, I/O, HTTP - this is exactly all the stuff I want to see removed
into separate dub packages and maintained as such.

> (they all are betterC modular libraries)

.. and this "betterC" weirdness you use with your own meaning is
definitely something I don't want to _ever_ see as standard library
approach. It is similar to `malloc` vs `GC` debate for Phobos, because
correct answer tends to be "neither", with rationale that any library
utility that has to care about the difference is hardly generic enough
for unconditional distribution.



My own dream path for fixing Phobos may look like this:

1) Start with separating environment-agnostic core (algorithms and
API's) from utilities
2) Rewrite all higher level utilities in a way that they don't have any
inter-dependencies and only allowed to use algorithm/API modules
3) Move higher level stuff into own dub packages with a special "Phobos"
category
4) When compiler is released, provide snapshot of latest up to date
packages in that category as part of the distribution for those who
don't want to bother with fetching manually

This actually may be even possible to do within a linear deprecation
process. On the other hand I doubt such drastic change to structure is
possible to be sold to community.



signature.asc
Description: OpenPGP digital signature

Re: ModuleInfo, factories, and unittesting

[Dicebot via Digitalmars-d]

On 12/18/2016 06:53 PM, Andrei Alexandrescu wrote:
> Compulsive ModuleInfo generation seems to be a drag. I'm not very
> familiar with the particulars but my understanding is ModuleInfo is
> needed for (a) Object.factory and (b) finding and running unittests.
> 
> Walter and I think Object.factory was a mistake and we'd like to make it
> opt-in long term (either by means of a build flag or a class attribute).
> 
> Until then, a very nice step forward is to NOT generate ModuleInfo if a
> module introduces no class.
> 
> For unittests, I figure things like static introspection should make it
> easier to enumerate and run unittests without a need for ModuleInfo.
> 
> What other issues/opportunities do you see related to ModuleInfo?
> 
> 
> Thanks,
> 
> Andrei

We rely on ModuleInfo for custom test runner in ocean
(https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/core/UnitTestRunner.d).
Static introspection can't provide same functionality in general case
(even if all bugs will be fixed) because it requires either maintaining
list of all modules or ensuring everything is imported from some root
module. Former is inconvenience, latter is simply not true for libraries
(though can be worked around by build system).





signature.asc
Description: OpenPGP digital signature

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Dicebot via Digitalmars-d]

On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu 
wrote:

Destroy.

https://github.com/dlang/DIPs/pull/51/files


Andrei


Proposed functionality does feel useful but syntax options 
mentioned in the DIP all seem lacking to me. Most importantly, 
the one suggested as primary option puts import after the symbol 
in lexical order which looks baroque and may even be 
unprecedented in the language (can't think of another case like 
that immediately).

Re: Joe Duffy on concurrency

[Dicebot via Digitalmars-d]

On Thursday, 1 December 2016 at 19:14:51 UTC, Dicebot wrote:

On Thursday, 1 December 2016 at 18:56:36 UTC, qznc wrote:
That is an interesting idea. Afaik, D does not allow to limit 
closure like this?


void i_only_accept_immutable_context (void delegate () 
immutable closure);


NB: it may have ton of bugs though, because delegate context 
suffers from type erasure in runtime

Re: Joe Duffy on concurrency

[Dicebot via Digitalmars-d]

On Thursday, 1 December 2016 at 18:56:36 UTC, qznc wrote:
That is an interesting idea. Afaik, D does not allow to limit 
closure like this?


void i_only_accept_immutable_context (void delegate () immutable 
closure);

Re: A simple solution for randomness copy problem

[Dicebot via Digitalmars-d]

One minor nitpick - please avoid calling postblit constructor a 
"copy constructor", it tends to mislead developers with C++ 
origins into expecting copy constructor they are used to - and 
disappointment when it proves to not be the case.

Re: interest in Static Analysis for D ?

[Dicebot via Digitalmars-d]

On 11/15/2016 07:05 PM, Stefan Koch wrote:
>> When doing so, try to forget that static analysis is the intended
>> goal. It has to be naturally usable for any other purpose too,
>> focusing on one specific application case is likely only harm design
>> decisions.
> 
> It's a compiler frontend.

Very good observation :P

> I cannot see any other purposes then code-analysis and code-transformation.
> Regarding Transformations I wanted to write a good D transformation tool
> for years now.

With that approach you can also say that code analysis is subset of code
of code transformation (it transforms code to list of warnings!) and
thus that is the only purpose. I doubt it is very useful definition :)

Language frontend as a library must allow any sort of reasoning about
source code that compiler can normally do. What library user will do
with that reasoning is not of ones concern - it can be analysis or
transpilation to another language or even dumb AST pretty-printing. No
matter, in the core one has to be able to do `import dlang.frontend` and
write own visiting code.



signature.asc
Description: OpenPGP digital signature

Re: interest in Static Analysis for D ?

[Dicebot via Digitalmars-d]

On 11/15/2016 06:46 PM, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 16:39:22 UTC, Dicebot wrote:
>> [  ]
>> But I'd sincerely advise against any ad-hoc solution that is built
>> into DMD itself.
> 
> It seems I did not clearly state this.
> I mean to provide the general plumbing that is needed for the dmd-fe,
> to utilize it for static analysis.
> I do not intend to cram all sorts of checking functionality inside the
> compiler.

When doing so, try to forget that static analysis is the intended goal.
It has to be naturally usable for any other purpose too, focusing on one
specific application case is likely only harm design decisions.



signature.asc
Description: OpenPGP digital signature

Re: interest in Static Analysis for D ?

[Dicebot via Digitalmars-d]

On 11/15/2016 04:57 PM, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I was wondering how much interest in static analysis exists in this
>> community .
>> DMD already has rudimentary support for these kinds of things.

I'd put it in a different perspective - we desperately need DMD FE (with
all semantic phases) available as fully-stand alone independent library.
For example, there is already DScanner
(https://github.com/Hackerpilot/Dscanner) for static analysis but amount
of things one can check with only lexer/parser is very limited in D.

Once we have such library, it opens up world of many useful tools -
separating all warnings into dedicated static analysis tool, providing
automatic project upgrade scripts which work reliably, visualize mixin
expansions and so on.

But I'd sincerely advise against any ad-hoc solution that is built into
DMD itself.



signature.asc
Description: OpenPGP digital signature

Re: GitHub now supports editing the target branch for PR

[Dicebot via Digitalmars-d]

On 11/12/2016 12:34 PM, Sönke Ludwig wrote:
> Not sure if this is common knowledge already, but it was new for me. If
> you click the edit button at the top of a pull request on GitHub, you
> now get a drop down to change the base branch to which the request will
> be pulled. Really handy for PRs that should be targeted at a stable
> branch, but instead target master.

I think I have sent 3 or 4 support request to GitHub asking about it and
finally it arrives! :) Makes even bigger difference if one has to
maintain multiple version branches as opposed to plain stable/master.



signature.asc
Description: OpenPGP digital signature

Re: {DMD-AST-Tool} For beginning DDMD hackers

[Dicebot via Digitalmars-d]

On 11/13/2016 10:40 AM, Stefan Koch wrote:
> On Saturday, 12 November 2016 at 10:26:53 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I have written a small utility called dmd-ast-tool.
>> It can be used to quickly generate boilerplate code for dmd-ast-visitors.
>> Originally it was only written for my personal use, it used to work
>> with a handwritten text-file representing dmds ast class hierarchy.
>>
>> However I recently updated it construct the class hierarchy from ddmds
>> source code.
>>
>> It is pretty bare-boned, but maybe it can be useful to some of you :)
>>
>> https://github.com/UplinkCoder/dmd-ast-tool.
> 
> I have just added a bit of code to modify the ast-nodes.
> It can also print a few stats about dmd.
> For example the names of the visitors implemented in dmd.

You may want to consider adding it to https://github.com/dlang/tools




signature.asc
Description: OpenPGP digital signature

Re: [OT] Re: CTFE Status

[Dicebot via Digitalmars-d]

On 11/10/2016 06:07 AM, Nick Sabalausky wrote:
> On 11/08/2016 02:11 PM, Antonio Corbi wrote:
>>
>> Maybe this one is useful for you:
>>
>> http://eagain.net/articles/git-for-computer-scientists/
> On 11/08/2016 03:01 PM, H. S. Teoh via Digitalmars-d wrote:
>> Nothing immediately comes to mind, but thanks to Dr. Google, I found
>> this page that's sorta helpful:
>>
>> http://ericsink.com/vcbe/html/directed_acyclic_graphs.html
>>
>> And perhaps these:
>>
>> http://eagain.net/articles/git-for-computer-scientists/
>> http://marklodato.github.io/visual-git-guide/index-en.html
>>
> 
> Ok, so it looks like each node in the DAG is a commit. I'll definitely
> have to read further. Thanks, both.
> 
> Although I have my doubts it would explain all the issues I've hit upon
> with git's CLI. For example: I don't see why annotated tags aren't the
> default. Or why non-annotated ones even exist at all. When I made
> , I noticed that it'll
> *only* work if the version tags are "annotated" tags. Because otherwise
> "git describe" doesn't retrieve the tag. Doesn't even matter one bit
> *what* the tag's message is, just that it exists. Why? Who knows! It's git!

Studying git object model in more details actually explains that.
Annotated tag is a first class git object (like commit), while plain tag
is simply a reference to existing object (like branch). From usability
PoV difference can be negligible but impact on git internals is huge.

The fact that the default is non-annotated tag is still just plain bad
decision though :)

> Its things like that. I'd be surprised if that has much to do with git's
> nature as a "dumb" DAG tool. It's just the general good-design principle
> of "The thing you *want to* or *should* do or *expect* 99% of the time
> should be the DEFAULT, not the obscure incantation".

I think it is related, but is not necessary consequence. My
understanding is that for a long time command line design was given zero
thoughts on its own - it was directly exposing whatever git does
internally with no usability considerations. Which is why it is so
awkward to use unless you really do know internal object model in great
details.



signature.asc
Description: OpenPGP digital signature

Re: Paging Walter Bright: Contextual Keywords

[Dicebot via Digitalmars-d]

On Monday, 7 November 2016 at 13:24:20 UTC, Timon Gehr wrote:

On 07.11.2016 12:38, Dicebot wrote:

On 11/07/2016 08:40 AM, Stefan Koch wrote:
Why not make it a plain identifier ? We give identifier 
special

meaning in various places, like scope(exit).


If I am not mistaken we do not need body ay at all.


It is matter of how smooth deprecation phase is. Completely 
removal of
`body` is OK long-term but that would mean one have to wait 
several
years of deprecation phase before it can be used as identifier 
in user
code. Making it deprecated _and_ contextual results in 
immediate

availability.



What's the new syntax for contracts if body is removed?


Currently https://github.com/dlang/DIPs/pull/48  
(https://github.com/MetaLang/DIPs/blob/8f3ac3a133cd1f9095dd992f38ae377f5987caa4/DIPs/DIP1003.md) proposes either use `function` keyword instead of `body` or simply omit it with two blocks following each other.

Re: Paging Walter Bright: Contextual Keywords

[Dicebot via Digitalmars-d]

On 11/07/2016 08:40 AM, Stefan Koch wrote:
>> Why not make it a plain identifier ? We give identifier special
>> meaning in various places, like scope(exit).
> 
> If I am not mistaken we do not need body ay at all.

It is matter of how smooth deprecation phase is. Completely removal of
`body` is OK long-term but that would mean one have to wait several
years of deprecation phase before it can be used as identifier in user
code. Making it deprecated _and_ contextual results in immediate
availability.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On Tuesday, 1 November 2016 at 06:04:41 UTC, Laeeth Isharc wrote:

On Monday, 31 October 2016 at 09:52:55 UTC, Dicebot wrote:

On 10/30/2016 06:35 PM, Laeeth Isharc wrote:

But what I meant was LLVM will have a wasm backend.


Yes, but it is developed so slowly and conservatively, that 
coming up with own proof-of-concept backend may be a chance to 
win early interest. They may speed up greatly though when 
WebAssembly design gets closer to MVP stage, but I am checking 
that regularly.


I was disappointed that after early hype it all went quiet for 
now.


Actually, they have moved one with browser previews and dedicated 
web site jsut as we were talking: http://webassembly.org


I am curious how much attention it will gather on i.e. reddit

But right now it is mostly irrelevant because runtime 
requirements have not been defined in WebAssembly at all, only 
low level byte code stuff. It is all in very early stages 
really.


You have looked into it more than me at a low level, but how is 
it possible then to run an app today in nightly browser in wasm?


How it works right now is that you can use WebAssembly byte-code 
to write a JavaScript-exposed function to be called from plain 
JavaScript. See http://webassembly.org/docs/js . Thus most of 
runtime level stuff is actually done by JS.


There are further plans to expose browser GC inside WebAssembly, 
allow direct usage of browser API like DOM and generally make 
possible to use it with no JavaScript at all - but those are all 
out of scope of MVP milestone.


Taking a step back,  it's quite amusing how much ingenuity goes 
into having to avoid writing Javascript...


Judging by focus points in public statements one can reason that 
actually main driving goal of WebAssembly developers is not to 
throw away JavaScript but to make existing JavaScript/asm.js code 
more efficient (by pre-compiling it on server and distributing in 
binary form).


At the same time such initiative is of great value to company 
like Google who has lost "better JS" competition (remember Dart 
language?) to Microsoft TypeScript. Having common ground in form 
of byte code supported by all browsers will in some way reset the 
competition again.

Re: CTFE Status

[Dicebot via Digitalmars-d]

Thank you and keep doing awesome stuff ;)



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
> But what I meant was LLVM will have a wasm backend.

Yes, but it is developed so slowly and conservatively, that coming up
with own proof-of-concept backend may be a chance to win early interest.
They may speed up greatly though when WebAssembly design gets closer to
MVP stage, but I am checking that regularly.

> So on basis of my
> limited understanding,  it would be some work to make LDC produce wasm
> code,  and then runtime and phobos would need work.

Most likely you would need a quite different runtime as most system/libc
level stuff will not be available in browser sandbox but the very same
browser APIs will need to be exposed instead. Most likely whatever
emscripten does for C should be fairly adaptable even outside of LLVM stack.

But right now it is mostly irrelevant because runtime requirements have
not been defined in WebAssembly at all, only low level byte code stuff.
It is all in very early stages really.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/30/2016 07:53 AM, Walter Bright wrote:
> On 10/29/2016 10:30 PM, Dicebot wrote:
>> At the same time intended wasm spec
>> (https://github.com/WebAssembly/design) is
>> much more simple than machine code for something like x86_64. If
>> Walter gets
>> interested, that may be a feasible path :)
> 
> I looked at it for 5 minutes :-) and it looks like typical intermediate
> code that a compiler might generate. It wouldn't be hard to translate
> the intermediate code generated for the dmd back end to wasm. What I
> didn't see was any mention symbolic debug information, linking, or how
> to connect to system services like mutexes, I/O, etc. Time risks would
> also be wasm is an incomplete, moving target.

Well, "risk" and "opportunity" are pretty much synonymous in such
context :) Whoever comes first with easy to use toolchain for new
platform gets all the hype - it pretty much boils down to making
decision if one believes new platform is likely to succeed.

For now I am just keeping my track on relevant information to see where
does it all go.

> Looks like a fun project, but I don't see how I could split off time to
> work on it.

No argument here, it would be premature to pay much attention to it
anyway. I will probably remind you of this topic some time next year
with more information available so that more weighted judgment can be made.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote:
Any thoughts on how much work is involved to port the runtime?  
And what other changes might be involved? The chap that used 
the C backend for LLVM wrote a little mini runtime but I guess 
didn't have to worry about the version blocks in the compiler 
front end as much.   (don't recall what architecture he 
pretended to be compiling to).


Glibc has obviously already been ported to run in browser by 
emscripten.


I have actually meant something quite different - implementing 
new backend for DMD which emits wasm directly (possibly by 
embedding binaryen). That is more work than simply using LLVM 
stack as-is but would result in unique marketing advantage - 
existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is 
rather annoying. And native wasm backend for LLVM is in 
development for quite a while now with no clear ETA.


At the same time intended wasm spec 
(https://github.com/WebAssembly/design) is much more simple than 
machine code for something like x86_64. If Walter gets 
interested, that may be a feasible path :)

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/27/2016 07:12 PM, Laeeth Isharc wrote:
> On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote:
>> On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M Davis wrote:
>>> On Thursday, October 27, 2016 15:42:53 Chris via Digitalmars-d wrote:
 Not easy to be smart with Javascript ;)
>>>
>>> Sure, it is. Avoid it. ;)
>>>
>>> - Jonathan M Davis
>>
>> I wish I could! I wish we had DScript for browsers!
> 
> I am hoping that when asm.js is more mature,  then we can use the llvm
> back end to write at least part of front end in D.   Would need runtime
> ported of course.

I consider native compiler from D to WebAssembly to be one of possible
unique breakthrough points for D in coming years.




signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/27/2016 11:24 AM, qznc wrote:
> I'm unsure about Linus' version. For this example, I agree that it is
> elegant. It is fine in this specific case, because everything is local
> within a single function. In general, the trick to use a pointer to the
> element probably not a good idea.
> 
> The article/Linus does not explain the tradeoffs properly, which makes
> it dangerous advice.

I'd agree for some general language but considering it is Linus, C can
be reasonably assumed. And in C land it doesn't even count as "trick",
heavy nested pointer usage is widespread and even somewhat idiomatic -
being comfortable with such code can be expected from any non-newbie C
programmer.



signature.asc
Description: OpenPGP digital signature

Re: Namespace for a module defined by its import path

[Dicebot via Digitalmars-d]

On 10/24/2016 11:06 PM, Jeff Thompson wrote:
> ...

If I really had to do something like that and there was no other way,
I'd most likely resort to auto-generating such module names during build
pipeline.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/26/2016 12:53 AM, Walter Bright wrote:
> It's a small bit, but the idea here is to eliminate if conditionals
> where possible:
> 
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

I find it both funny and saddening how many reddit commentators
complained about Linus version of that code is over-complicated.

"Prefer clear code over smart code" principle is good in general but
sometimes it is over-applied to the point where incompetence gets
glorified. And this sucks.



signature.asc
Description: OpenPGP digital signature

Re: Review manager wanted: core.vmm

[Dicebot via Digitalmars-d]

On Tuesday, 25 October 2016 at 15:08:14 UTC, Dmitry Olshansky 
wrote:

Hi, have you found a review manager yet?


No, the NG was rather silent, so sill looking for one.


As it is a runtime module and not Phobos, I'd be willing to 
volunteer - but only quite some time later (probably about 1 
month). Ping me via e-mail if no one else comes by that time.

Re: I close BIP27. I won't be pursuing BIPs anymore

[Dicebot via Digitalmars-d]

On 10/17/2016 05:44 AM, deadalnix wrote:
> On Monday, 17 October 2016 at 02:08:44 UTC, Dicebot wrote:
>> Listen, I understand you are not interested in spending loads of time
>> on boring polishing of formalities. We all do this in our spare time
>> so that is to be expected.
>>
> 
> I spent fuck 4;5 years on that thing. Don't come at me saying I'm not
> interested in polishing it. I'm not interested in wasting my time.
> That's entirely different.

You did a rather terrible job if that DIP document was a result of 4.5
year effort. And that is the most polite thing I can say about such
statement.

Let's make it clear - https://github.com/dlang/DIPs/pull/16 featured a
great idea and that was the ONLY positive bit about it. Structure and
clarity of explanations are plain terrible. It looks more like throwing
in the proposal with "now you go figure it out" attitude than a formal
document.

You never took requests to make it more clear to the heart, making only
trivial tweaks. Clear signs of how DIP is lacking in clarity (the very
irrelevant comments and long pause times) are now interpreted as process
issue, but in fact those are your personal issue as DIP author.

If you think those demands are not acceptable - new process was not
designed for you and I am happy I have not wasted more of my time trying
to get it into shape.



signature.asc
Description: OpenPGP digital signature

Re: I close DIP27. I won't be pursuing DIPs anymore

[Dicebot via Digitalmars-d]

On 10/18/2016 02:40 AM, David Soria Parra wrote:
> On Monday, 17 October 2016 at 21:52:32 UTC, Andrei Alexandrescu wrote:
>> Thanks, David. Hope you're doing well! I was curious about one thing -
>> is there some scrutiny going into the PIPs before Guido reviews them?
>> Right now we seem to have a scalability issue; some of the DIPs we
>> have seem to be no more than a couple of hours of work from the
>> submitters. Writing a good review for a submission that needs a lot of
>> improvement is in many ways more difficult than reviewing a
>> well-argued DIP.
>>
>> I was therefore wondering - given Python's popularity - whether there
>> is some filtering of PIPs prior to them being reviewed by Guido.
> 
> PEPs (sorry I totally misspelled that before) have a editors who are
> responsible for scrutinizing the PEP before and as far as I understand
> are the ones who can request review from the BDFL (Guido), who either
> takes the final decision or delegates it (e.g. in cases were someone is
> better suited in the area to make the call). Editors are trusted core
> committers that are sponsoring an improvement.
> 
> The process is outline in great detail at
> https://www.python.org/dev/peps/pep-0001/#pep-workflow and I recommend
> reading it. Maybe we get some good ideas on how to create a process that
> is scalable and results in the high quality standards we have but are
> more suited towards the smaller community we are.
> 
> We should start small and see how we find something that Walter, you and
> contributors feel good about and improve from there:
> 
> might suit our needs.

But this is pretty much the process we have right now! Differences I can
see:

- currently I am the only person acting as a preliminary "editor"
- I don't hold right to reject anything, only to request more
information/improvements
- it features decision delegates to someone else but BDFL is certain cases
- transition between various stages is more formally defined

I doubt anyone complaining about existing DIP process would have a
slightest chance to get a PEP of similar quality and style accepted as a
draft.



signature.asc
Description: OpenPGP digital signature

Re: Advanced const propagation for structs

[Dicebot via Digitalmars-d]

On 10/17/2016 12:57 AM, Timon Gehr wrote:
> On 16.10.2016 14:18, Dicebot wrote:
>> This issue has been discussed before in context of custom containers and
>> AFAIK so far no one was able to come up with even theoretical concept of
>> how it can be possibly addressed.
> 
> Actually, I did propose a solution before. Just allow annotations on
> template type parameters (to enable the new implicit upcasts) and check
> for binary compatibility of the respective template instances during
> implicit conversion.

Can you find a link to that post? I don't remember anything like that.



signature.asc
Description: OpenPGP digital signature

Re: I close BIP27. I won't be pursuing BIPs anymore

[Dicebot via Digitalmars-d]

Listen, I understand you are not interested in spending loads of 
time on boring polishing of formalities. We all do this in our 
spare time so that is to be expected.


But what you say here only shows that process is working as 
intended - and that it is not suitable for you. Quote from 
readme: "Be prepared for a lot of work. There are always many 
ideas proposed but far fewer developers commited to pursuing the 
idea to the final stages of evaluation. The DIP system is not for 
submitting undeveloped ideas, it is a process for formal approval 
of language changes".


There isn't any lack of ideas in D community. Those don't hold 
much value on its own. What is needed is commitment and 
stubbornness, and DIP system, among other things, helps to not 
pay attention to those who are unlikely to pursue their idea to 
an end.


On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:

The DIP process is beyond broken. It essentially goes as :
 - If you are Andrei or Walter, then your DIP is just a 
formality. No matter how bad it is, it is in (Hi DIP25, inout 
turned out so great for type qualifier we clearly need that for 
lifetime).


This is explicitly mentioned in README. Like it or not, but this 
is reality we have to live with and there is no point in 
pretending otherwise. Walter won't change and you can either try 
to make best of the status quo or move on to other things.


 - If anybody else does it, you have no idea what you are 
getting into. You'll be still there in 5 years with no end in 
sight.


I've been a sucker for long enough. I'm not playing anymore and 
I'd suggest to anyone playing to stop. I've probably be playing 
longer than pretty much anyone here. Trust the bitter old man, 
he knows.


.. and trying to convince others that your specific choice is 
"correct" is a shitty move.

Re: Advanced const propagation for structs

[Dicebot via Digitalmars-d]

On 10/16/2016 11:36 AM, Ilya Yaroshenko wrote:
> Hi,
> 
> Extern precompiled Mir GLAS requires additional API changes.
> Reduced example:
> 
> ```d
> struct S(T)
> {
>   size_t len;
>   T ptr;
> }
> 
> auto foo(S!(const(double)*) sl)
> {
> }
> 
> S!(double*) a;
> const S!(double*) b;
> 
> foo(a); // fails
> foo(b); // fails
> 
> ```
> 
> https://issues.dlang.org/show_bug.cgi?id=16616

This issue has been discussed before in context of custom containers and
AFAIK so far no one was able to come up with even theoretical concept of
how it can be possibly addressed. The issue is crazy complicated because
of how D templates work:

struct S (T)
{
static if (is(typeof(T) == const))
int a;
else
string  a;
}

const S!(int) one;
S!(const int) two;

pragma(msg, typeof(one.a)); // string
pragma(msg, typeof(two.a)); // int



signature.asc
Description: OpenPGP digital signature

Re: Idea for a new tool

[Dicebot via Digitalmars-d]

On 10/14/2016 06:01 PM, Chris Wright wrote:
> On Fri, 14 Oct 2016 09:13:16 -0400, Andrei Alexandrescu wrote:
> 
>> https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei
> 
> For the love of potatoes, please take a few seconds to tell us the gist 
> of it here.
> 
> The requested tool is a preprocessor, of sorts: evaluate version 
> statements and mixins and expand templates. That lets you see what's 
> going on in your code a bit better in the case of extensive 
> metaprogramming.

This wouldn't be a pre-processor in C/C++ sense because it requires full
semantic analysis to work. More like a special mode of compilation.



signature.asc
Description: OpenPGP digital signature

Re: Challenge

[Dicebot via Digitalmars-d]

On Monday, 3 October 2016 at 13:50:26 UTC, John Colvin wrote:
The problem is that function pointers in "is" expressions don't 
match "function" or "delegate".


static assert (is(void delegate() == delegate)); //passes
static assert (is(void function() == function)); //fails
static assert (is(void function() == delegate)); //fails

Bug report?


Note that there is at least some code that relies on current 
behavior to distinguish delegate/function fields from method 
declarations in aggregates.

Re: Challenge

[Dicebot via Digitalmars-d]

On Monday, 3 October 2016 at 13:41:13 UTC, Manu wrote:

I'm finding this rather annoying:

struct S
{
  static @property int p() { return 10; }
}

pragma(msg, typeof(&S.p)); // prints: int function() @property
pragma(msg, is(typeof(&S.p) == function)); // prints: false

It looks like a function... but I can't identify it as a 
function!



It works if both:

a) you remove @property
b) you don't convert it to function pointer

struct S
{
   static int p() { return 10; }
}

pragma(msg, is(typeof(S.p) == function); // true

Sadly `is(X == function)` is very obscure and confusing because 
it doesn't do what one may expect it to do. In current form it 
can only be used if something is a function declaration, 
everything else is `false`. It is not even possible to manually 
express a type which will pass `is(T == function)`, you can only 
get `true` by applying `typeof` to existing function declaration.


And @property screws it because the only current effect of 
property is exactly changing result of `typeof(propertyFoo)` from 
function type to result type.

Re: The worst Phobos template (in binderoo)

[Dicebot via Digitalmars-d]

On Saturday, 1 October 2016 at 15:06:44 UTC, Stefan Koch wrote:

On Saturday, 1 October 2016 at 10:19:21 UTC, Dicebot wrote:

On 09/29/2016 07:02 PM, David Nadlinger wrote:

[...]


What are the issues with fullyQualifiedName in that context? I 
mean other than Voldemort types of course. I'd expect `static 
import` + `fullyQualifiedName` combo to be reasonably reliable 
and used it a lot in the past. Do you refer to aliases with 
changed protection attributes?


The problem is the default template parameter Flag!"unsafe",
because fqn makes it into "cast(Flag)".
Getting this right is a bit tricky.


Isn't it a problem with library implementation though, one that 
would be easy to fix if FQN is to become a compiler built-in?


Reason why I'd like to have something akin to FQN for code 
generation is because it allow to generate (and save to file) 
non-templated methods directly importing required symbols (only 
generator function has to be templated). This can be of great 
importance if you consider classes and virtual methods.

Re: Anyone has time for a unittesting issue?

[Dicebot via Digitalmars-d]

On Saturday, 1 October 2016 at 19:32:08 UTC, Andrei Alexandrescu 
wrote:
Not like this is real security concern in dmd case but 
guidelines like
"don't make /tmp/ path predictable" exist exactly so that one 
can have

simple safe default and not worry about possibilities.


This may be a misunderstanding. I'm saying is to switch from 
unpredictable paths rooted in /tmp/ to equally unpredictable 
paths rooted in /tmp/.dmd-test-run/.


I think that is OK but only if actual file inside the dir is 
created with `mktemp --tmpdir=/tmp/.dmd-test-run/` (or using a 
similar technique). I wonder if Phobos provides any 
cross-platform way to do so - I remember some PR on topic but in 
current documentation there seems to be nothing useful mentioned,

Re: Anyone has time for a unittesting issue?

[Dicebot via Digitalmars-d]

On Saturday, 1 October 2016 at 18:24:07 UTC, Andrei Alexandrescu 
wrote:
Granted, no contest. Seems to me we could be a better denizen 
of said junkyard. What I noticed other apps do is create one 
directory in /tmp and then place their junk in there. -- Andrei


Yeah, it is both common and "wrong" (considered insecure) :) 
Problem is that it allows one to hijack output from the binary 
and redirect it somewhere else. If binary is running as 
privileged user, it can possibly be used as an attack vector.


Not like this is real security concern in dmd case but guidelines 
like "don't make /tmp/ path predictable" exist exactly so that 
one can have simple safe default and not worry about 
possibilities.


Sure, it makes things less pretty, but beauty of /tmp/ layout is 
hardly an important goal to follow. It seems like more practical 
issue is simply that no regular destruction of /tmp/ happens on 
your system.

Re: Anyone has time for a unittesting issue?

[Dicebot via Digitalmars-d]

On Saturday, 1 October 2016 at 17:45:30 UTC, Dicebot wrote:
On Saturday, 1 October 2016 at 17:35:29 UTC, Andrei 
Alexandrescu wrote:
I think /tmp/ is mounted per user so we should be good. 
Anyhow... care to send a PR upstream? -- Andrei


You can't make any assumptions about how /tmp/ is mounted, it 
is completely up to distro/administrator.


As for original post - it is not an issue. The whole /tmp/ 
content can be wiped between sessions (it is not uncommon to 
mount it into RAM) - there should never be need to only remove 
dmd related parts. The whole point of /tmp/ is to be a random 
junkyard.

Re: Anyone has time for a unittesting issue?

[Dicebot via Digitalmars-d]

On Saturday, 1 October 2016 at 17:35:29 UTC, Andrei Alexandrescu 
wrote:
I think /tmp/ is mounted per user so we should be good. 
Anyhow... care to send a PR upstream? -- Andrei


You can't make any assumptions about how /tmp/ is mounted, it is 
completely up to distro/administrator.

Re: [OT] google- and github-fu: how to search for a specific PR?

[Dicebot via Digitalmars-d]

On 10/01/2016 03:33 PM, Andrei Alexandrescu wrote:
> I was looking for the PR that changed iota.length and it took me longer
> than it could have. I googled for
> 
> iota length dlang
> 
> and among the top results I found the changelog PR:
> https://github.com/dlang/phobos/pull/4220, but it was through
> indirections via mail-archive.com. Same goes about the actual result
> (https://github.com/dlang/phobos/pull/4013) which was further down the
> page.
> 
> Are there any shortcuts? It would help a lot if one could search
> github.com repos for PR titles, is that possible?
> 
> 
> Thanks,
> 
> Andrei

https://github.com/search?q=iota+length+dlang+&type=Issues&utf8=%E2%9C%93

Is that good enough? Relevant PR is the second entry there for me.



signature.asc
Description: OpenPGP digital signature

Re: The worst Phobos template (in binderoo)

[Dicebot via Digitalmars-d]

On 09/29/2016 07:02 PM, David Nadlinger wrote:
> On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner wrote:
>> Any chance to get this one working:
>>
>> import std.typecons;
>>
>> enum Stuff
>> {
>> asdf,
>> }
>>
>> void main()
>> {
>> BitFlags!Stuff a;
>> mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
>> }
> 
> This wouldn't be a correct use of the feature anyway, since it runs into
> all sorts of fundamental issues with imports/scoping, aliases and
> templates. Using .stringof/fullyQualifiedName to generate a reference to
> a type or symbol in a string mixin is a mistake, period. Unfortunately,
> the misconception that they *are* code generation tools is fairly
> wide-spread, to the point where dlang.org contains a similarly
> misleading comment. [1]

What are the issues with fullyQualifiedName in that context? I mean
other than Voldemort types of course. I'd expect `static import` +
`fullyQualifiedName` combo to be reasonably reliable and used it a lot
in the past. Do you refer to aliases with changed protection attributes?



signature.asc
Description: OpenPGP digital signature

Re: DIP 1002 (TryElseExpression) added to the queue

[Dicebot via Digitalmars-d]

On 09/28/2016 09:47 AM, Andrei Alexandrescu wrote:
> ...

I have added references to both your and Walter comments to DIP1002
review section: https://github.com/dlang/DIPs/pull/44




signature.asc
Description: OpenPGP digital signature

Re: DIP 1002 (TryElseExpression) added to the queue

[Dicebot via Digitalmars-d]

On 09/28/2016 01:17 PM, pineapple wrote:
> On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote:
>> * Please remove colloquialisms. Characterizations such as
>> "fantastically useful" are unlikely to be a convincing motivator and
>> have no place in a DIP.
>>
>> * The "Description" section should be more detailed and less casual.
>> The grammar changes should be shown in a syntax similar to the current
>> grammar definition.
> 
> These were not documented as a requirement anywhere that I saw. I'd have
> been happy to comply, if I had known this was the practice.

As the new DIP process is very young, set of requirements is being
fleshed out as we go. Basically what happens is that DIP gets into the
queue, Andrei and Walter point out what they don't like and I take
notice of it to add to the documented requirements.

Merged draft DIPs are not set in stone - Andrei's comment is not sign of
immediate rejection but a request to make a PR to improve mentioned things.

>> * The "Breaking changes" section should include how the following
>> change in semantics would be addressed. Consider:
>>
>>   try
>> if (expression)
>> try { ... }
>> catch (Exception) { ... }
>> else { ... }
>>   finally { ... }
>>
>> This code is currently legal and binds the "else" clause to the "if"
>> and the "finally" to the first "try". The proposed feature will bind
>> the "else" and the "finally" to the second try and then probably fail
>> to compile because there is no "catch" or "finally" matching the first
>> "try".
> 
> This possibility hadn't occurred to me. Is that really legal?

Yes. `try` body is a single statement or block and `if/else` is a legal
single statement. Same for `if` statement and `try/catch`.

> If so, I'd argue ... that
> people shouldn't write such ambiguous code.

Proposing language change is a serious responsibility and speculations
about how developers should or should not write their code have no place
there.

If something is currently legal, breaking changes sections _must_
provide means to mitigate the damage or proposal should not be accepted
no matter how good it is.



signature.asc
Description: OpenPGP digital signature

Re: Linking D code into existing C programs

[Dicebot via Digitalmars-d]

Don't think it can be made much better for object files but it 
should be relatively simple to enable creating "C-friendly" 
static D libraries that include all required runtime bits as part 
of the library.

DIP 1002 (TryElseExpression) added to the queue

[Dicebot via Digitalmars-d]

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md

PR: https://github.com/dlang/DIPs/pull/43

Abstract:

In Python, the try/catch/finally syntax is augmented with an 
additional clause, termed else. It is a fantastically useful 
addition to the conventional syntax. It works like this:


```
try:
do_something()
except Exception as e:
pass # Runs when an error inheriting from Exception was 
raised

else:
pass # Runs when no error was raised
finally:
pass # Runs unconditionally, evaluates last
```

Re: Should #line create a new namespace ?

[Dicebot via Digitalmars-d]

On 09/24/2016 10:14 AM, Basile B. wrote:
> When the file is specified, Shouldn't #line create a new module ?
> 
> ===
> module m;
> 
> int a;
> 
> #line 0 "other.d"
> 
> int a;
> ===
> 
> Currently this is not allowed, but what's the value added by the
> filename then ?

It was used to easier debug string mixins by changing their filename in
reported errors. Now it is done by compiler by default and I don't know
if any other use case remains.

But is definitely is not intended to create a new module, D relies on
strict 1-to-1 matching between files and modules.



signature.asc
Description: OpenPGP digital signature

Re: we push flatbuffers for dlang support, no one to help?

[Dicebot via Digitalmars-d]

On Friday, 23 September 2016 at 11:15:32 UTC, rikki cattermole 
wrote:
I pushed a lot of code and tests to your PR, I don't really 
know whats

missing now. imo its usable already but they don't merge it


"Need a CLA for one or more commit authors"


Also "Still see no documentation, for example".

Re: The worst Phobos template (in binderoo)

[Dicebot via Digitalmars-d]

On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch 
wrote:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch 
wrote:


I would like to see users of fullyQualifiedName because apart 
from binderoo code which seems to work, I have none.


That was supposed to say : I would like to see [test cases 
from] users of fullyQulifiedName.


I wrote a type overload of it long time ago to be used in vibe.d 
REST interface generator - combined with static imports it 
ensured symbol hygienne. Though it possible current 
implementation doesn't use it anymore.


Intended semantics was to be as close to this as possible:

mixin("alias T2 = " ~ fqn!T);
static assert(is(T2 == T));

In that sense builtin trait could be a better option.

Re: Struct default constructor - need some kind of solution for C++ interop

[Dicebot via Digitalmars-d]

On Sunday, 11 September 2016 at 08:37:56 UTC, deadalnix wrote:

On Sunday, 11 September 2016 at 06:09:01 UTC, Dicebot wrote:
Presence of compile-time valid T.init for any type T is 
absolutely critical for generic programming and must not be 
compromised.


WAT ?


Vast amount of traits operate on is(typeof(do stuff with T.init)) 
- all of them will return false negative for types with init 
disabled.

Re: Struct default constructor - need some kind of solution for C++ interop

[Dicebot via Digitalmars-d]

Presence of compile-time valid T.init for any type T is 
absolutely critical for generic programming and must not be 
compromised.

Re: Struct default constructor - need some kind of solution for C++ interop

[Dicebot via Digitalmars-d]

On Thursday, 8 September 2016 at 09:54:51 UTC, Ethan Watson wrote:

On Thursday, 8 September 2016 at 09:33:01 UTC, Dicebot wrote:
Instead, it would be much more constructive (pun unintended) 
to focus on language changes to extern(c++) class bindings to 
make them suitable for the task - those won't affect anyone 
but C++ interop users.


I agree in principle, but it doesn't help me right now. It's 
holding up my work, which means it's costing someone money. 
Workarounds will have to suffice until the language can be 
updated.


As a workaround I sincerely believe explicit 'create' (with 
forged mangling if needed) is better. It provides exactly the 
same functionality without tricking the developet into expecting 
more by confusion of the syntax similarity.

Re: Struct default constructor - need some kind of solution for C++ interop

[Dicebot via Digitalmars-d]

On Wednesday, 7 September 2016 at 12:28:41 UTC, Ethan Watson 
wrote:
On Wednesday, 7 September 2016 at 12:14:46 UTC, rikki 
cattermole wrote:

http://dlang.org/phobos/std_typecons.html#.scoped


This is the kind of hackaround I'd need to do if it were a 
class... And it would require more hacking around than the 
standard library supports. And it's a spiraling-out-of-control 
hack, which would effectively mean every C++ matching class 
will need to define a class and then an alias with the scoped 
type, and then that means the pattern matching I've been 
creating for function linkups won't work any more...


static opCall() and a static alloc function for allocating on 
the heap are still looking like the simplest options here.


They aren't. It won't also be used if you declare new instance on 
stack via `S s`. Staic opCall is 100% identical to any other 
static factory method in its semantics (i.e. static S create()).


What I am trying to say is thta prohibiting struct default 
constructors is an intentional language design decision in D, 
with a lot of consequences. There is literally no chance it can 
be tricked.


Instead, it would be much more constructive (pun unintended) to 
focus on language changes to extern(c++) class bindings to make 
them suitable for the task - those won't affect anyone but C++ 
interop users.

Re: Struct default constructor - need some kind of solution for C++ interop

[Dicebot via Digitalmars-d]

On Wednesday, 7 September 2016 at 11:35:45 UTC, Daniel Kozak 
wrote:

Dne 7.9.2016 v 13:16 Ethan Watson via Digitalmars-d napsal(a):

On Tuesday, 6 September 2016 at 14:49:20 UTC, Ethan Watson 
wrote:

this( void* pArg = null );


Also doesn't work: this( Args... )( Args args ) if( 
Args.length == 0 )


Just for funsies I tried making my Mutex a class for the 
purpose of embedding it manually in a struct. But thanks to 
all classes inheriting from Object there's 16 bytes at the 
front of the class that I don't want (64-bit build, it's 8 
bytes in 32-bit builds but we're never going back to 32-bit). 
So that's very definitely out of the question.

Even extern(C++) class ?

https://dlang.org/spec/cpp_interface.html#classes


If it is so, I'd call it a major extern(c++) bug.

Re: Struct default constructor - need some kind of solution for C++ interop

[Dicebot via Digitalmars-d]

static opCall() seems to be the only way to do this then. I can 
autogenerate it for any C++ bound class. But it's inadequate. 
It leaves room for user error when instantiating any C++ object 
in D. It's also another thing that C++ programmers need to be 
thoroughly educated about as Type() in C++11 calls the zero 
initializer, but in D it's effectively the opposite semantics.


Please try out everything possible instead of resorting to static 
opCall. It is a terrible hack, both confusing and inconsistent 
(won't apply if you allocate struct on heap) that got popular 
simply because some devs were unhappy with language decision to 
prohibit default ctors. It never makes sense to use it, literally 
never.

Re: Struct default constructor - need some kind of solution for C++ interop

[Dicebot via Digitalmars-d]

Is using svope class out of the question?

Re: Quality of errors in DMD

[Dicebot via Digitalmars-d]

On Sunday, 4 September 2016 at 10:46:25 UTC, develop32 wrote:
Certainly just stating that an assert was triggered in this and 
this line of the backend is not enough?


Often it is actually enough because compiler developer can check 
last changes to related code and propose simple checks to nail it 
down.


There shouldn't be any reason to not report ICE to bugzilla, no 
matter how few data can ne provided.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Dicebot via Digitalmars-d]

On 09/03/2016 07:52 PM, Martin Nowak wrote:
> On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
>> I don't agree with the current solution:
> 
> Well let's come up with a better solution then.
> Let's start by finding some proper use-cases that require introspection
> on private members w/o having access to them.

Obviously serialization libraries come to mind, especially important for
binary serialization because private members still affect the layout of
the struct.



signature.asc
Description: OpenPGP digital signature

DIP1001: DoExpression

[Dicebot via Digitalmars-d]

DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md

Abstract


A DoExpression do(x,y,z) is exactly equivalent to a CommaExpression
(x,y,z), but doesn't emit a deprecation warning.

==

First community DIP has just landed the review queue. Please express
your opinion and suggestions - it will all be taken into consideration
when the formal review time comes.



signature.asc
Description: OpenPGP digital signature

Re: Low level unit test library in druntime

[Dicebot via Digitalmars-d]

On Friday, 2 September 2016 at 19:26:41 UTC, Jacob Carlborg wrote:

On 2016-09-01 14:02, Dicebot wrote:

What would be different? List of unit test blocks available in 
the program?


How the unit tests are written and collected.

unittest { assert(true); }

class FooTest : Test
{
void testFoo() { assert(true); }
}

describe("foo", {
it("does something", {
assert(true);
});
});


Then we perfectly understand each other and I will vote against 
introducing any other way/syntax for writing _unit_ tests in D 
with all my passion.

Re: Quality of errors in DMD

[Dicebot via Digitalmars-d]

On 09/02/2016 06:45 PM, Wyatt wrote:
> On the other, though, considering he's been using DMD for years and
> didn't know that, I think there's a cogent argument for improving even
> ICE messages.  At the least, have them print "Internal Compiler Error".

Great idea, I hacked a quick implementation to make all asserts to
direct to bugzilla: https://github.com/dlang/dmd/pull/6103



signature.asc
Description: OpenPGP digital signature

Re: ADL

[Dicebot via Digitalmars-d]

On 09/02/2016 03:15 PM, Manu via Digitalmars-d wrote:
> In C++, there is this ADL thing (argument dependent lookup).
> What it does is, when searching for overloads, in addition to looking
> in the local namespace, it also looks in the namespace of the function
> arguments.

AFAIR it is intentionally not supported to simplify symbol lookup rules.

> I have the same configuration across 2 modules in D.
> In one module, I receive the foreign modules type via template arg,
> but I haven't imported that type's module, so when I try to call the
> function it can't find the overload, because it's not imported, and it
> doesn't search the argument type's module (ie, namespace) for
> overloads.

Don't know about best practice but I tend to simply find the host module
for the argument and mixin the import for it inside the template to make
symbols directly available.



signature.asc
Description: OpenPGP digital signature

Re: Low level unit test library in druntime

[Dicebot via Digitalmars-d]

On 09/01/2016 07:17 PM, ZombineDev wrote:
> On Thursday, 1 September 2016 at 12:06:21 UTC, Dicebot wrote:
>> On 08/31/2016 01:01 PM, Atila Neves wrote:
>>> And never mind that any such low level library would suffer from the
>>> same problem unit-threaded did until dub fixed it: D can't reflect on
>>> packages so a program must be written that explicitly lists all
>>> modules that need to be looked at.
>>
>> I don't even think fixing package reflection would truly help here
>> because there exist legit D projects that don't transitively import
>> all modules from `main` and recursive compile-time visiting of all
>> symbols would miss them.
>>
>>> [snip]
> 
> Not a problem, since you can do things like this:

It is exactly _THE_ problem. You can't have the imaginary test runner to
reliably find all tests automatically, at least all compiled modules
have to be listed explicitly. This is not good, thus I am inclined to
call extending RTTI an only viable long-term solution.




signature.asc
Description: OpenPGP digital signature

Re: Low level unit test library in druntime

[Dicebot via Digitalmars-d]

On 08/31/2016 01:01 PM, Atila Neves wrote:
> And never mind that any such low level library would suffer from the
> same problem unit-threaded did until dub fixed it: D can't reflect on
> packages so a program must be written that explicitly lists all modules
> that need to be looked at.

I don't even think fixing package reflection would truly help here
because there exist legit D projects that don't transitively import all
modules from `main` and recursive compile-time visiting of all symbols
would miss them.

> There's a disconnect between what's possible at runtime with ModuleInfo
> and what's possible at compile-time with __traits(getUnittests).
> Fortunately for me, running unit-threaded itself as an executable with
> dub fixed the problem, but in the general case this proposal would
> suffer from the same problems. Unless we force everyone to use dub.

To me it feels like mandatory per-requisite for any test runner changes
in druntime right now is to:

1) make compiler emit runtime info on test block basis instead of per module
2) store TypeInfo of unittest block attributes as part of that runtime info



signature.asc
Description: OpenPGP digital signature

Re: Low level unit test library in druntime

[Dicebot via Digitalmars-d]

On 08/30/2016 10:40 PM, Jacob Carlborg wrote:
> On 2016-08-30 18:31, Dicebot wrote:
> 
>> I definitely wouldn't want to use API like you proposed if I was to
>> write my own test runner. Minimal common ground which would be cool to
>> have is getting range/array of all unittest blocks together with their
>> annotations. Anything more than that is optional luxury that specific
>> test systems may define.
> 
> Basically the only thing that would be different in different frameworks :(

What would be different? List of unit test blocks available in the program?

>> And any usage of classes in what is supposed to be a base ground API is
>> immediate "no" for me :)
> 
> Yeah that would be crazy, like threads, fibers, sockets and exceptions ;)

_forcing_ usage of threads, fibers, sockets and exceptions in runtime
outside of their respective modules would be rather outrageous too.
druntime should reasonably simple to port to systems that may not have
any of those - and still degrade gracefully.



signature.asc
Description: OpenPGP digital signature

Re: So why was typedef bad?

[Dicebot via Digitalmars-d]

On 08/31/2016 04:44 PM, Ethan Watson wrote:
> http://dlang.org/deprecate.html#typedef
> 
> "typedef is not flexible enough to cover all use cases. This is better
> done with a library solution."
> 
> [Citation needed]
> 
> What use cases is it not flexible enough for?

It has unadjustable semantics that were both more restrictive than alias
and at the same time not restrictive enough to introduce completely new
type. Wasn't supposed to be compatible with base type but sometimes did,
with no reasons other than "historical".

In my own experience creating dedicated struct type is always superior
to typedef if you want to go for type safety. It can start with simple
`alias this` struct to have permissive semantics similar to old typedef
and later changed to operator overloading for more fine tuned control.
It can also provide methods for verified conversion between base type
and new domain type.

And if type safety is not a goal, there isn't much point in all the
typedef restrictions and alias should do as well.



signature.asc
Description: OpenPGP digital signature

Re: Low level unit test library in druntime

[Dicebot via Digitalmars-d]

On 08/30/2016 07:17 PM, Jacob Carlborg wrote:
> The reason to put in the druntime is because that's where the existing
> runner is located.
> 
> The advantage of this low level library is that:
> 
> * Third party unit test library don't need to reinvent the wheel
> 
> * All third party libraries using this low level library would be
> compatible and can be combined in the same project
> 
> * If we would like to, it would be easy to extend the existing runner,
> like not stopping on the first failure. _Not_ saying that we should

I definitely wouldn't want to use API like you proposed if I was to
write my own test runner. Minimal common ground which would be cool to
have is getting range/array of all unittest blocks together with their
annotations. Anything more than that is optional luxury that specific
test systems may define.

And any usage of classes in what is supposed to be a base ground API is
immediate "no" for me :)



signature.asc
Description: OpenPGP digital signature

Re: Low level unit test library in druntime

[Dicebot via Digitalmars-d]

Definitely not in druntime. Optional extra test runners in Phobos (or
libraries for higher level test suites) are reasonable but I don't want
any changes to fundamentals of how _unit_ tests are defined and used.




signature.asc
Description: OpenPGP digital signature

Re: Why D is not popular enough?

[Dicebot via Digitalmars-d]

On 08/30/2016 01:50 PM, John Burrton wrote:
> This is why the example on the front page put me off for a long time :-
> 
> stdin
> .byLineCopy
> .array
> .sort!((a, b) => a > b) // descending order
> .each!writeln;
> 
> It makes the language look like some weird high level functional
> language where you don't ask how it works and you shouldn't care how it
> maps to the machine instructions and memory.

On a related point I think it is important to emphasize that such
pipelines are cool not because they look high-level but also because
with decent inlinining compiler (LDC/GDC) they generate as efficient
code as for hand written C style implementation based on loop.

There are plenty of languages that allow similar kind of high level
programming but it usually comes with considerable overhead, contrary to D.

Though this specific is not very good as it requires lot of allocation
by the algorithm used. My favorite short snippet I commonly use when
evangelizing D is splitting stdin by whitespaces:

void main ( )
{
import std.stdio, std.algorithm, std.uni;

stdin
.byLine // note that no byLineCopy is needed here
.map!(line => line.splitter!isWhite)
.joiner
.each!writeln;
}

It is 100% Unicode correct, does not allocate any memory garbage and
does exactly what told to do while being orders of magnitude more
readable than any C style loop version one can come up with.



signature.asc
Description: OpenPGP digital signature

Re: Dip Discussion

[Dicebot via Digitalmars-d]

On Sunday, 28 August 2016 at 22:16:47 UTC, Illuminati wrote:
I don't know how you can make such an assertion. It's like 
saying that if there were no humans around to breath there 
would be no oxygen. You have to build something first for it to 
be used and grow, not the other way around, which is illogical. 
People can't use something if it doesn't exist, so you can't 
claim that for it to be created(put in to existence) that first 
people need to use it("have traffic"). The better you build 
something the more people will use it. If you can't build it 
well then no need to beat around the bush.


I am saying that any system does not come for free and has both 
setup and ongoing costs. It has to be justified by the fact that 
existing approach doesn't work anymore, "it is cool" or even "it 
is better" is not enough. D workforce is simply not large enough 
to afford commitments of limited importance.

Re: Dip Discussion

[Dicebot via Digitalmars-d]

On Sunday, 28 August 2016 at 18:17:51 UTC, Illuminati wrote:
Maybe for each Dip it would be nice to have a discussion or 
comments section exposed in some way. A full fledged 
subforum(per DIP) would be better so contrasting threads could 
be followed easier.


For now intention is to aggregate all discussion threads / 
reviews / mail list archives via links in DIP itself. Thanks for 
reminding about it btw, I have just added 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#reviews


Adding something more complicated can be considered but we don't 
have that much DIP related information traffic yet to make extra 
complexity worthwhile.

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/22/2016 08:22 PM, H. S. Teoh via Digitalmars-d wrote:
>> 3. separate compilation
> 
> Under the current state of separate compilation, yes.  But in theory it
> *should* be possible, at least in some of the common use cases.

Separate compilation is perfectly fixable if we agree for it to work on
package / static library level and not on module / object file level.
But that may need .di generation improvements and the `export` proposed
changes from Benjamin.



signature.asc
Description: OpenPGP digital signature

Re: Examples block

[Dicebot via Digitalmars-d]

On Saturday, 20 August 2016 at 20:39:13 UTC, Engine Machine wrote:

We have a unittest, what about an examples?


https://dlang.org/spec/unittest.html#documented-unittests

Re: [OT] of [OT] I am a developer and I hate documentation

[Dicebot via Digitalmars-d]

On 08/19/2016 02:50 AM, karabuta wrote:
>> Sigh.  Eventually we're just reinventing Markdown in ddoc. Why can't
>> we just use Markdown (with some ddoc extensions) in the first place?
>>
>>
>> T
> 
> That will be way better, don't know why markdown is not used already.

There is https://github.com/kiith-sa/harbored-mod which supports
markdown in addition to base ddoc. We are actually switching to it as a
standard internal documentation generator at Sociomantic.



signature.asc
Description: OpenPGP digital signature

Re: Compiler analysis of single-use types? Escape analysis of types?

[Dicebot via Digitalmars-d]

On Thursday, 18 August 2016 at 06:29:07 UTC, Ali Çehreli wrote:

On 08/17/2016 05:59 PM, Dicebot wrote:
> On 08/18/2016 12:25 AM, Ali Çehreli wrote:
>> I'm wondering whether there is such a thing as single-use of
a type in
>> compiler technology. I think if the compiler could determine
that a type
>> is used only once, it could apply optimizations.
>>
>> A colleague of mine raised the issue of D's use of the GC
even for
>> seemingly local delegates. For example, even though
everything remains
>> local for the following lambda, countAbove() cannot be @nogc:
>>
>> auto countAbove(int[] a, int limit) {
>> return a.filter!(x => x >= limit).count();
>> }
>>
>> The reason is due to the fact that filter() returns a struct
object that
>> takes the delegate as an alias template parameter. Here is a
reduction
>> of the issue with my understanding in comments:
>
> I believe actual reason is that aliased lambda has to
allocate a closure
> because it refers to stack local variable (limit).

Right.

> This compiles just fine:
>
> auto countAbove(int[] a, int limit) @nogc {
> return a.filter!(x => x >= 1).count();
> }

However, as my test code demonstrates, even when the lambda 
refers to stack local variable, closure is NOT allocated in the 
case of the function call. As far as I can tell, the actual 
reason for the allocation is the struct object that filter() 
returns.


I am trying to understand why the struct object requires the 
closure allocation. I made myself believe that this is the 
reason: Being an alias template parameter, the lambda is a part 
of the type (the instantiation of the struct template). Even 
though the compiler could determine that the single object does 
not escape, its type can be used again.


Your main mistake seems to be an expectation of complete flow 
analysis in compiler while in fact it is virtually non-existent. 
DMD frontend can't prove that references to stack don't escape in 
all but most simple cases (where all involved code is fully 
inlined and no actual function/struct has to be generated).


For example, in your struct case it can't know that you won't 
eventually return that struct instance from function or do 
something similar. Such analysis is simply not performed, thus it 
has to generate code conservatively. The problem you mention is 
likely to be present with current frontend too but that is not a 
crucial technical limitation on its own because fully qualified 
type of such S instantiation would include function-local context 
and compiler can use it to tell that type can be optimized as 
function-local unless any references escape.


From my own encounters vast majority of issues of that kind could 
be solved by one of two relatively simple solutions:


1) Being able to capture context in lambda by value (Right now I 
tend to use custom structs with `opCall` instead of built-in 
lambdas for such cases)


2) Allowing compiler to treat `pragma(inline, true)` functions as 
ones that never generate own object code and thus can be analyzed 
in usage contexts separately.

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/12/2016 01:24 PM, Robert burner Schadek wrote:
>> No, the DIP doesn't handle several levels of indirection.
> 
> What about:
> 
> struct Bar { int a; int b }
> auto rcs = RefCountedTree!(string,Bar)();
> 
> fcs["bar"].a = 1337;  // log n
> fcs["bar"].b = 1338;  // log n
> 
> ? I need to pay log n twice to assign two members

Note though that while it won't work with example of `RefCountedSlice`
implementation in DIP (which marks return value as scope reducing
lifetime to expression), it should be possible to instead mark method
itself (== hidden `this` argument) as `return scope` thus saying that
return value has same lifetime as `this`.





signature.asc
Description: OpenPGP digital signature

Re: Compiler analysis of single-use types? Escape analysis of types?

[Dicebot via Digitalmars-d]

On 08/18/2016 12:25 AM, Ali Çehreli wrote:
> I'm wondering whether there is such a thing as single-use of a type in
> compiler technology. I think if the compiler could determine that a type
> is used only once, it could apply optimizations.
> 
> A colleague of mine raised the issue of D's use of the GC even for
> seemingly local delegates. For example, even though everything remains
> local for the following lambda, countAbove() cannot be @nogc:
> 
> auto countAbove(int[] a, int limit) {
> return a.filter!(x => x >= limit).count();
> }
> 
> The reason is due to the fact that filter() returns a struct object that
> takes the delegate as an alias template parameter. Here is a reduction
> of the issue with my understanding in comments:

I believe actual reason is that aliased lambda has to allocate a closure
because it refers to stack local variable (limit). This compiles just fine:

auto countAbove(int[] a, int limit) @nogc {
return a.filter!(x => x >= 1).count();
}



signature.asc
Description: OpenPGP digital signature

Re: ISO D

[Dicebot via Digitalmars-d]

On 08/17/2016 02:34 PM, eugene wrote:
> On Wednesday, 17 August 2016 at 10:47:35 UTC, qznc wrote:
>> On Wednesday, 17 August 2016 at 08:02:42 UTC, eugene wrote:
>>> will ISO D be in future or not?
>>
>> What would be the benefits?
> 
> unified language standard?

Unified among whom? There is only one feature complete D frontend right
now. I'd say that the moment second competing frontend appears would be
exactly the proper time to think about formal standartization.



signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/15/2016 02:52 PM, Walter Bright wrote:
> On 8/15/2016 2:32 AM, Kagamin wrote:
>> On Sunday, 14 August 2016 at 20:02:35 UTC, Walter Bright wrote:
>>> auto r = range;
>>
>> You said that if a value (range in this case) is returned by scope,
>> its lifetime
>> is restricted to its expression, hence it can't be assigned to a
>> variable,
>> because the variable outlives the expression.
> 
> A very good question. If the functions parameters are 'return scope',
> that means the returned value has the (smallest) scope if its 'return
> scope' parameters. If there are no 'return scope' parameters, the scope
> of the return value is limited to the expression.

Does that mean that a scope return in aggregate method will bind to
aggregate lifetime if method itself is annotated with scope too? For
example:

struct Container
{
scope Range asRange ( ) scope
{
return Range(&this.data);
}
}




signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/15/2016 12:32 PM, Kagamin wrote:
> On Sunday, 14 August 2016 at 20:02:35 UTC, Walter Bright wrote:
>> auto r = range;
> 
> You said that if a value (range in this case) is returned by scope, its
> lifetime is restricted to its expression, hence it can't be assigned to
> a variable, because the variable outlives the expression.

As far as I understood Walter, his explained behaviour should happen if
function is NOT annottated with scope and will be a default out-of-box
one when trying to "borrow" stack-allocated data. Not sure yet how it
should work with more complex cases (i.e. container stores a slice /
pointer internally and not just int).



signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/14/2016 10:50 PM, Walter Bright wrote:
> On 8/14/2016 7:42 AM, Dicebot wrote:
>> Two another more nitpicky comments:
>>
>> 1) Deprecation process proposal right now says this:
>>
>> - remove -scope, issue warning when errors are detected
>> - replace warnings with deprecation messages
>>
>> PLEASE FOR THE SAKE OF ALL DEAR NEVER EVER DO THIS
>>
>> Deprecations must always come first. Warnings may or may not follow
>> later but any deprecation process must mandatory start with deprecation
>> message, not exceptions and no excuses.
> 
> Hmm, but we've always done warning => deprecation => error

Yes, and it was a major disaster because most sensible projects compile
with warnings as errors enabled (it is also the default in dub) and thus
putting a warning breaks a many more times more code than putting a
deprecation. We have already talked that through before with Martin and
it seemed acknowledged that pattern has to be changed to "deprecation ->
(optional warning) -> error".



signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/14/2016 11:02 PM, Walter Bright wrote:
> It's a bit advanced, but it falls entirely in the DIP rules and is
> workable with some implementation effort (not sure how much).
> 
> The idea is, if something is ultimately a stack variable, the scope
> rules apply.

That is an unexpected application of described rules - I feel like I
need some time to fit it into my head before I can respond :)




signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

Two another more nitpicky comments:

1) Deprecation process proposal right now says this:

- remove -scope, issue warning when errors are detected
- replace warnings with deprecation messages

PLEASE FOR THE SAKE OF ALL DEAR NEVER EVER DO THIS

Deprecations must always come first. Warnings may or may not follow
later but any deprecation process must mandatory start with deprecation
message, not exceptions and no excuses.

2) Ignoring `scope` for variables with no indirections.

The fact that DMD is extremely accepting when it comes to nonsense
declarations/attributes has been is notable contribution to harming
learning curve. It often tricks new developers into thinking that their
code is checked for something when in fact compiler simply silently
skips extra annotations.

Instead, nonsense application of `scope` to data with no indirections
should be deprecated completely as part of overall deprecation process
for implementing the proposal.



signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/10/2016 11:36 PM, Dicebot wrote:
> http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org

I am still uncertain myself about the proposal, mostly because can't
completely grasp rules for returning as scope. My litmus test example is
very simple (for desired semantics):

```
struct Container
{
int data;

static struct Range
{
int* pdata;
// range methods skipped for clarity ..
}

Range asRange ( )
{
return Range(&this.data);
}
}

void main ( )
{
Container container;

import std.stdio;
writeln(container.asRange()); // case 1, OK

scope r = container.asRange(); // case 2, OK
auto r = container.asRange(); // case 3, not OK
}
```

It looks like
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#scope-function-returns)
I can annotate `scope Range asRange ( )` to force result into rvalue and
make case 1 and case 3 work as desired but there is no way to express
lifetime relation between returned struct and host container so that
case 2 will work.

If it is indeed correct, I am going to call it a complete showstopper.
Any scope proposal is of interest to me only if it can be used to
implement some form of borrowship semantics (even awkwardly looking) on
top - everything else is a nice addition to have but in no way justifies
added language weight.

Note that section
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#owning-containers
explain similar example (but with refcounting instead of stack
allocation) but it does not show semantics at call site and is either
subject to same limitation (can't store result of `opIndex`) or
contradicts previous spec.



signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/11/2016 11:07 AM, Jacob Carlborg wrote:
> On 10/08/16 22:36, Dicebot wrote:
>> http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
>>
>> The first DIP has just landed into the new queue. It is a proposal from
>> language authors and thus it bypasses usual nitpicking process and
>> proceeds straight to requesting community (your!) feedback.
>>
>> Essentially, it is an attempt to solve reference lifetime problem by
>> extending implementation of `scope` keyword.
>>
>> Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
> 
> DIP 1_000? Is this the one DIP to rule them all, making all the 900 DIPs
> or so you skipped over not necessary :)

I have decided to start counting new DIPs from 1000 so that it is
immediately clear when someone casually mentions "DIP N" if the person
refers to old or new queue.



signature.asc
Description: OpenPGP digital signature

DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org

The first DIP has just landed into the new queue. It is a 
proposal from language authors and thus it bypasses usual 
nitpicking process and proceeds straight to requesting community 
(your!) feedback.


Essentially, it is an attempt to solve reference lifetime problem 
by extending implementation of `scope` keyword.


Proposal text: 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md


Few notes:

- Please submit pull requests to adjust the markdown document if 
you want to propose any improvements (mentioning @WalterBright 
and @andralex for confirmation).
- The proposal refers to a number of other documents and it is 
recommended to become familiar at least briefly with all of them.
- At this point the question I'd personally suggest to be 
evaluated is "does this proposal enable enough useful designs?". 
A good check would be to try taking some of your projects and see 
if having DIP1000 approved and implemented could improve them.

Re: Things that make writing a clean binding system more difficult

[Dicebot via Digitalmars-d]

On 07/29/2016 03:55 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, July 29, 2016 14:14:49 Dicebot via Digitalmars-d wrote:
>> What you want it contradictory to the concept of "storage class".
> 
> Why? I thought the the whole idea of "storage class" was that it was an
> attribute that was applied to a type that wasn't actually part of the type.
> Certainly, based on past discussions on the topic, it seems to be that the
> term is used for pretty much anything that gets applied to a type that isn't
> actually part of the type. And that's definitely what happens with ref.
> 
> - Jonathan M Davis

Storage class has to attach to some symbol to modify its semantics
without affecting the type, it doesn't apply to type at all. Usually it
is a variable and that comes naturally but in case of function return
value / parameters the only available symbol is function itself -
contrary to variables, parameters are not available as independent
symbols AFAIK.

That said, `ref` isn't a 100% storage class, otherwise `alias Foo = ref
int function ( )` wouldn't work. Judging by only observable semantics
I'd say it is more akin to type qualifier contrary to what spec says -
but qualifier of function type.

Re: Things that make writing a clean binding system more difficult

[Dicebot via Digitalmars-d]

On 07/29/2016 02:05 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
>> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
>>> I've always looked at D's ref as being essentially the same as C++'s &
>>> except that it's not considered to be part of the type, just attached to
>>> it
>>> in a way that doesn't propagate. The same with with in or out. I just
>>> don't
>>> see how it even makes conceptual sense for ref to be an attribute of the
>>> function itself.
>>
>> C++'s & is a bizarre type constructor in that it has completely wacky and
>> special cased behavior in just about everything involving types, including
>> type deduction, type inference, overloading, etc. For example, you can't
>> have a pointer to a ref. Or a ref of a ref. Sometimes the ref is considered
>> part of the type, sometimes not. Etc.
>>
>> With D, making it a sort of storage class completely sidesteps that mess.
> 
> I understand that part. It's treating it like a function attribute that
> makes no sense to me. Even if it's not treated as part of the return type
> exactly, it's still the return type that it's affecting, not the function.
> ref, in, and out are all in this kind of weird place where they affect a
> type without being part of the type, and I'm guessing that because of how
> oddball they are, there really wasn't a good way to deal with ref on the
> return type, since it wasn't actually part of the type, so in the
> implementation, it got tied to the function instead rather than trying to
> add a new concept to the compiler. So, I guess that from an implementation
> perspective, it makes some sense, but it's still downright weird given that
> ref really has to do with the return type and not the function itself, even
> if ref is a storage class rather than actually being part of the type.

What you want it contradictory to the concept of "storage class".

Re: Long term @nogc / allocators usage

[Dicebot via Digitalmars-d]

Also in general usage of custom allocator for temporaries is a 
very bad @nogc approach and is only marginally better than GC 
using code. Good @nogc must make no decisions about allocations 
at all (and ideally minimize stack allocations too, especially if 
fibers are to be used).

Re: Long term @nogc / allocators usage

[Dicebot via Digitalmars-d]

@nogc code is quite different from idiomatic "casual" D code and 
one is expected to make sacrifices to go for it. Here are some 
approaches I decided for myself:


On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
Now, there are some cases in which you cannot avoid the managed 
allocations:
1) throwing exceptions: these should not be abandoned in favor 
of other solutions; IMHO, they should be easily usable in @nogc 
code; switching to error codes or user-defined callbacks is not 
feasible in general;


Use pre-allocated exception instances. Throwing itself doesn't 
require GC, only allocating exception does. You can possibly 
screw up exception chaining this way but this is a very minor 
loss.


2) returning arrays: sometimes you just can't avoid this: if 
your function must return a string, than it has to allocate it 
(unless it's a slice of some input)


If it can't be avoided, this is not @nogc code and there is no 
point in pretending otherwise. Use ranges and sinks instead to 
move allocations decisions up the call chain. Note that with sink 
approach you want be able to mark function itself @nogc (because 
sink delegate allocates) but you can mark unittest block that 
verifies there are no _other_ allocations:


void foo ( alias sink_dg ) ( )
{
sink_dg("abc");
}

@nogc unittest
{
void noop_sink ( const(char)[] chunk ) @nogc { }
foo!noop_sink();
}