On 9/2/2014 7:07 AM, Dmitry Olshansky wrote:
>  Make distinctive name like assumeSafe and it's going to be trivially grepable.

We already have a distinctive name, @trusted. Adding an panopoly of more names make it not so trivially greppable.


> So there is need, but somehow requires a bunch of useless boilerplate, like
> repeating arguments and inventing creative names for local functions.

In the example I gave, it wasn't actually necessary to repeat the arguments. This will work as well:

      void checkEquals() @trusted {
         assert(msg.length == msg2.length);
         assert(memcmp(msg.ptr, msg2.ptr, msg.length) == 0);
       }

But the parameterized one was better encapsulated by being pure.


> So you think adding boilerplate will make function more easily verifiable?

Encapsulating the trusted operation, not the components of the trusted operation, make it more easily verifiable.

On 9/2/2014 10:11 AM, Daniel Murphy wrote:
> Yes, that function is more easily verifiable for @safety, because any violation
> _must_ be inside the @trusted function.

The 'pure' attribute helps with that.


> If the @safe violating helpers were
> used, main would effectively be @trusted and more lines would need to be reviewed.

Yes, that says it better than I did.

On Tuesday, 2 September 2014 at 17:19:28 UTC, ketmar via Digitalmars-d wrote:
> yes, i'm relatively new in D world and my position may look like
> extremist one, but all i want is to make D better. that's why i'm
> writing those posts instead of sitting silently in my shell. i know
> that we can't change C or C++, but i believe that we can change D. not
> by throwing in random features, but by making D more consistent, better
> looking and more pleasant to use.

After following these forums for quite some time I think the roll-your-own-as-proof-of-concept is the best approach. If it is better and the compiler is capable of taking mainstream D as well as your own syntax then others will follow and there will be pressure to implement it in the main branch. There is just waaaay to much resistance to improve the D syntax to waste time arguing for it.

Time is better spent arguing for more performant/better semantics in the mainline and fix syntax in private builds until the wind changes direction… (and an alternative build that is better, yet remains compatible, is the best way to change direction the wind is blowing).

I'm rooting for you! :-)

On Tue, 02 Sep 2014 19:15:46 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> After following these forums for quite some time I think the roll-your-own-as-proof-of-concept is the best approach.
that's why we need "D powerpatches" site. i'm working on it, albeit
slowly. i see it as "patch repository", with descriptions, dependency
tracking ("patch xyz needs patch zxy applied first"), web interface and
CLI tool (something like very lightweight apt). maybe even with
"private repositories" which can be created by users.
so-called "dub for patches". ;-)

something like:

  dppm list
  dppm search
  dppm get uda_nothrow_pure trusted_block -- to get "combined patch"

and so on. maybe even with comment system for patchsets.

this is ambitious project, i know. but long time ago D was just a dream too. and this project will help me to improve my nearly non-existent vibe.d skills. ;-)

02-Sep-2014 22:50, Walter Bright пишет:
> On 9/2/2014 10:20 AM, Daniel Murphy wrote:
>> Having syntax (or a wrapper function) to do the second wrapping
>> automatically
>> would violate @safe.  If it was syntax, it would be banned in @safe.
>> If it's a
>> wrapping method like the proposed 'call', then it is a program error
>> for it to
>> be marked @trusted.
>
> I agree with monarch_data, this is the executive summary, the salient
> point, the money shot, etc.

Well, whatever. Let's wait to see where our code base goes.

-- 
Dmitry Olshansky

On Tuesday, 2 September 2014 at 19:38:47 UTC, ketmar via Digitalmars-d wrote:
> this is ambitious project, i know. but long time ago D was just a dream
> too. and this project will help me to improve my nearly non-existent
> vibe.d skills. ;-)

Another approach would be to cooperate on building an infrastructure where it is easy to have multiple parsers in the same build then have the ability so select parser and configure the parser syntax in the head of the file:

module.parser1(@attrs,simd,stuff) modulename;
or
module.parser2(pythonstyle, otherstuff) modulename;

That way you can even create a DSL and use it in select modules.

The main problem is string mixins where you probably will have to retain classic D syntax?

On 9/2/2014 12:40 PM, Dmitry Olshansky wrote:
> Well, whatever. Let's wait to see where our code base goes.


:-)

On Tuesday, 2 September 2014 at 18:50:19 UTC, Walter Bright wrote:
> On 9/2/2014 10:20 AM, Daniel Murphy wrote:
>> Having syntax (or a wrapper function) to do the second wrapping automatically
>> would violate @safe.  If it was syntax, it would be banned in @safe.  If it's a
>> wrapping method like the proposed 'call', then it is a program error for it to
>> be marked @trusted.
>
> I agree with monarch_data, this is the executive summary, the salient point, the money shot, etc.

+1 from me as the self-proclaimed resident @safe-ty philosopher. We might want to think about fixing the immediately invoked delegate literal inlining problem.

David

On Tue, 02 Sep 2014 20:04:51 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Another approach would be to cooperate on building an infrastructure where it is easy to have multiple parsers in the same build then have the ability so select parser and configure the parser syntax in the head of the file:
i'm still waiting for AST macros (DIP50). ;-)

actually, changing parsers is not that fun, 'cause writing parser needs "inner knowledge" about compiler and it's AST. and writing complete parser is very tedious. and you will not be able to write "whitespace sensitive" parser anyway, 'cause it needs new scanner and lexer.

in other words: i'm not ready for this challenge yet. i'd better stick with my patches and leave custom parsers for somebody else. such change will diverge ALOT from "mainline D" and syncing with git head will be even more time-consuming than doing full-time 8 hr. work. and i have nothing to sell right now to keep me alive and well-functioning without payed work. ;-)

On Tue, 2 Sep 2014 23:31:05 +0300
ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

p.s. i REALLY need to take English lessons.