Deprecate standard contracts

[axic]

Follow up from ethereum/solc-js#30.

Certain pieces of Solidity snippets are included during compilation when specifying the --add-std flag for solc. The list is available here:

solidity/libsolidity/interface/CompilerStack.cpp

Line 45 in 31aa67f

const map<string, string> StandardSources = map<string, string>{

:

@chriseth wants to deprecate them.

[Denton-L]

On it!

[redsquirrel]

Do you know if there's a plan for an actual standard lib that ships with Solidity?

[axic]

@redsquirrel I think the sentiment is to have package managers instead.

When I have time I do plan to update https://github.com/axic/density, but any help is more than welcome 😃

[redsquirrel]

Hm, in my experience, successful programming languages tend to have a standard library AND a strong package management ecosystem. Are we thinking that they are mutually exclusive for Solidity?

[axic]

@redsquirrel that is the sentiment I've gathered. I think it is very useful to have a thin, well-tested standard library (even Javascript has it with the many builtin types and methods over them). It is just really hard finding that fine line between core and auxiliary functions. Otherwise I wouldn't have started the discussion over the other thread months ago.

[bobsummerwill]

I guess we just don't have enough knowledge yet of what exactly what such a standard library might contain, and are reticent to "bless" something when we don't even have a packaging system.

With a packaging system in place there is an ecosystem supportive of standards starting to emerge.

Building a standard library now, up-front, would be a bit "Cathedral".

[redsquirrel]

@bobsummerwill Are there examples of successful programming languages that waited to build a standard library until after a packaging system was in place? I can't think of one, but my experience is limited to Perl, JavaScript, Java, and Ruby. I suggest biting the bullet and "blessing" some standard components in order to make Solidity a more productive programming environment.

@axic That fine line is extremely hard to find. But in my experience, successful languages tend to cross that line by putting too many auxiliary functions into their standard library. This leads to an annoying amount of std-lib bloat in hindsight, but was likely one of the reasons for the language's survival: early developers could depend on higher level abstractions and get down to the business of building even more powerful programs.

Just my 2 ETH 😄

[bobsummerwill]

We're in unchartered territory, though, aren't we, @redsquirrel?

We're not just making another general purpose language where the appropriate scope of a standard library can just mimic that of existing languages. "OK - let's do some containers, some strings, some file system, etc."

The risk of "blessing too early" is that you are then stuck with a support nightmare.

I imagine there is a fair bit of ad-hoc sharing happening already, eh? And a packaging system would make that much easier. Until you have a good idea of "the market", I certainly wouldn't want to be the one guessing what a standard library would look like.

Maybe others feel braver in such a guess?

[redsquirrel]

The risk of "blessing too early" is that you are then stuck with a support nightmare.

@bobsummerwill Can you say more about this?

[bobsummerwill]

Just that anything which is declared as "standard library" will likely have to be supported forever, that we will have to maintain backwards compatibility, even if the initial API turns out to ill-advised, etc.

While libraries are all "use at your own risk", we have wide latitude to fix issues even if they break backwards compatibility or change API.

Are there any Solidity libraries which are already broadly used?

[bobsummerwill]

Essentially do we know "What Good Looks Like?"

I don't know that we do yet.

[redsquirrel]

Why would the Solidity std-lib have to maintain backward compatibility forever? I mean, I agree that most languages tend to keep their std-libs around forever, but why is that uncharted territory in the context of Solidity? Do backward-incompatible changes to Solidity affect previously deployed contracts?

[redsquirrel]

Essentially do we know "What Good Looks Like?"

I'd say that owned and mortal are good enough to keep.

[bobsummerwill]

Let me point here from Gitter and get some more opinions on expectations of API stability.

[axic]

@redsquirrel @bobsummerwill can you please move this discussion to #228? It seems like it kind of derailed from the original :)

[bobsummerwill]

Yep

[chriseth]

@redsquirrel shipping a standard library with the compiler is the plan, but we don't have the capacity to do that at the moment.