June 27, 2020
On Thursday, 25 June 2020 at 15:52:01 UTC, aberba wrote:
> And some like D2 but cleaned out.

+1

If there is consensus on, for example, auto-decode as default needing to go, a branch could be blessed that does so and works out a way to stay in sync with the mainline. Just promote that so that new projects pick it up (existing ones would know to stick to mainline).

Anything on which there is consensus, do it without impacting existing code investments.
June 27, 2020
On Thursday, 25 June 2020 at 13:18:22 UTC, JN wrote:
> On Tuesday, 23 June 2020 at 16:57:04 UTC, Chris wrote:
>>
>> As for D3, a pity there are no plans for it, it galls me that D should remain in its current state as it undoubtedly has good features.
>
> What would your D3 contain? The problem is that many people have different vision for the "better D" and they are often incompatible. Some people for example would like to make @safe the default, some people would like to drop OOP, some people would like to drop the GC, many different ideas going on around.

Sorry, I didn't see your post. What would D3 contain? First of all, all half-baked features should go, anything that is only so-so and where it is evident that it doesn't work as it should because of conflicts with std.fancy etc., bin it.

In general, keep features that are industry proven, I'd say GC and OOP should be available. An alternative to GC too. So the first thing would be to check D3 against industry standards / use in general and also ask companies that use D specifically (what features they use and why etc.) There should be no ideological flamewars like OOP vs structs. If there's demand in the industry, keep that feature.

The rest, the bikeshedding bit about @safe etc., whatever is agreed upon in the end, it just has to be consistent. There's nothing worse for a developer than not knowing exactly what s/he's doing simply because the language is not clear about it. Clear and consistent rules. Also, talking about @safe and such features, one has to think about the long term implications of features. A feature might seem to be a good idea, but can cause loads of trouble in production. I think D has enough hindsight by now to make informed decisions. Informed, pragmatic, industry oriented - not ideological or nerdy.


June 29, 2020
On 6/26/20 10:30 PM, Yatheendra wrote:
> On Thursday, 25 June 2020 at 15:52:01 UTC, aberba wrote:
>> And some like D2 but cleaned out.
> 
> +1
> 
> If there is consensus on, for example, auto-decode as default needing to go, a branch could be blessed that does so and works out a way to stay in sync with the mainline. Just promote that so that new projects pick it up (existing ones would know to stick to mainline).
> 
> Anything on which there is consensus, do it without impacting existing code investments.

I think the first order of business would be to have a nothrow core that defines correcntess of inputs as preconditions. The rest of the library can use it underneath. For example maxElement would have a precondition that the range is not empty etc.

That also means finding new ways for APIs. std.conv.to would need a lambda to call if conversion fails, thus pushing policy to the caller.
June 29, 2020
On Monday, 29 June 2020 at 16:56:37 UTC, Andrei Alexandrescu wrote:
>
> I think the first order of business would be to have a nothrow core that defines correcntess of inputs as preconditions. The rest of the library can use it underneath. For example maxElement would have a precondition that the range is not empty etc.
>
> That also means finding new ways for APIs. std.conv.to would need a lambda to call if conversion fails, thus pushing policy to the caller.

Thanks for providing an anchor point for a clean-up effort.

Any more specifics? Like just spelling out if @nogc is a consideration.
June 29, 2020
On 6/29/20 2:32 PM, Yatheendra wrote:
> On Monday, 29 June 2020 at 16:56:37 UTC, Andrei Alexandrescu wrote:
>>
>> I think the first order of business would be to have a nothrow core that defines correcntess of inputs as preconditions. The rest of the library can use it underneath. For example maxElement would have a precondition that the range is not empty etc.
>>
>> That also means finding new ways for APIs. std.conv.to would need a lambda to call if conversion fails, thus pushing policy to the caller.
> 
> Thanks for providing an anchor point for a clean-up effort.
> 
> Any more specifics? Like just spelling out if @nogc is a consideration.

A nogc subset would also be nice, but more difficult to define.

Any attempt to version std or carve subsets thereof would need an early experiment that is relatively easy from a coding standpoint. That way the work can focus on the scaffolding aspects (does lookup work well? how do we do documentation and testing? any incompatibility issues? etc) without getting also mired in new bugs and other technical issues.
June 29, 2020
On Monday, 29 June 2020 at 16:56:37 UTC, Andrei Alexandrescu wrote:
> On 6/26/20 10:30 PM, Yatheendra wrote:
>> [...]
>
> I think the first order of business would be to have a nothrow core that defines correcntess of inputs as preconditions. The rest of the library can use it underneath. For example maxElement would have a precondition that the range is not empty etc.
>
> That also means finding new ways for APIs. std.conv.to would need a lambda to call if conversion fails, thus pushing policy to the caller.

Or return a SumType/Either/Expected/etc?
June 29, 2020
On 6/29/20 6:58 PM, aliak wrote:
> On Monday, 29 June 2020 at 16:56:37 UTC, Andrei Alexandrescu wrote:
>> On 6/26/20 10:30 PM, Yatheendra wrote:
>>> [...]
>>
>> I think the first order of business would be to have a nothrow core that defines correcntess of inputs as preconditions. The rest of the library can use it underneath. For example maxElement would have a precondition that the range is not empty etc.
>>
>> That also means finding new ways for APIs. std.conv.to would need a lambda to call if conversion fails, thus pushing policy to the caller.
> 
> Or return a SumType/Either/Expected/etc?

Affirmative!
June 30, 2020
On Monday, 29 June 2020 at 18:38:45 UTC, Andrei Alexandrescu wrote:
>
> A nogc subset would also be nice, but more difficult to define.
Spelling that out was useful. I wasn't thinking of such subsets, whose definitions would need a big-picture view. Too ambitious.


> Any attempt to version std or carve subsets thereof would need an early experiment that is relatively easy from a coding standpoint. That way the work can focus on the scaffolding aspects (does lookup work well? how do we do documentation and testing? any incompatibility issues? etc) without getting also mired in new bugs and other technical issues.

What would be a workable way to attempt this? Maybe Boost-like? An external d. package which judiciously private-imports std, core, etc. It might convince more contributors. I don't know about users; this shouldn't look like the OCaml situation (2 external _replacements_ for its standard library), people who'd happily include Boost might be equally happy to import d.

Also, I know libmir is a highly-differentiated tangent, but would it hypothetically be what a reorganized Phobos could become? If not, it is useful to enumerate which aspects are undesirable in Phobos.
June 30, 2020
On 2020-06-30 02:45, Andrei Alexandrescu wrote:
> On 6/29/20 6:58 PM, aliak wrote:
>> Or return a SumType/Either/Expected/etc?
> 
> Affirmative!

So the first thing to do would be to come up with a unified error reporting mechanism that doesn't use exceptions.

I like the zero overhead exceptions C++ proposal [1]. That requires language support, but it would allow us to use the existing try-catch-finally syntax.

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

-- 
/Jacob Carlborg
1 2
Next ›   Last »