Usage of "return" is a good idea.
The more heads the better result :)
Thanks. Dmitry.
On Mon, Feb 9, 2015 at 11:48 AM, Joe Watkins <pthre...@pthreads.org> wrote:
> Morning internals,
>
> I really liked the original idea Dmitry had, with the D-ish syntax.
>
> We could use require and return like:
>
> function foo()
> require(input-expr)
> return(output-expr) {
> /* ... */
> }
>
> to avoid adding more keywords.
>
> I'd really appreciate seeing this as an option in the RFC.
>
> Cheers
> Joe
>
> On Mon, Feb 9, 2015 at 8:44 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>> It's nothing wrong here. It's just a concept that cares about constraints
>> definition more.
>>
>> So, DbC with asserts spread among the code is like OOP without classes.
>>
>> Thanks. Dmitry.
>>
>>
>> On Mon, Feb 9, 2015 at 2:11 AM, Stanislav Malyshev <smalys...@gmail.com>
>> wrote:
>>
>> > Hi!
>> >
>> > > Following our conversation, I tried to imagine how DbC should look
>> like
>> > in
>> > > PHP from user perspective. Finally, I was influenced by the semantic
>> > > proposed in D, and syntax proposed for Java. So, these are my initial
>> > > thoughts:
>> > >
>> > > For php it may look like the following:
>> > >
>> > > function foo()
>> > > requre(<input-assert-expression>)
>> > > ensure(<output-assert-expression>)
>> > > {
>> > > ...
>> > > }
>> >
>> > Why not do it simpler?
>> >
>> > function foo() {
>> > // require
>> > assert(<input-assert-expression>);
>> > ...
>> > // ensure
>> > assert(<output-assert-expression>);
>> > }
>> >
>> > I'm oversimplifying a bit, but in general, why we need more places to
>> > have code in the function than the actual code of the function? It would
>> > be harder to parse, to read, to maintain, to debug, to profile, etc. and
>> > I'm not sure what exactly it provides that can't be done by plain
>> > regular code inside the function.
>> >
>> > If we're concerned about the costs of assert, we could make special
>> > provision in the compiler for zero-cost asserts. It doesn't require
>> > moving code out of the function.
>> > --
>> > Stas Malyshev
>> > smalys...@gmail.com
>> >
>>
>
>
