Language feature: Add support for binary literals

[alexfertel]

Abstract

There is no way to declare an integer using a binary literal.

Motivation

It is easier to use binary literal notation for several use cases. For example, when using bitmasks, it's more readable to write 0b00111111 than 0x3f. It probably makes sense to include support for octal literals as well.

Specification

I'm not familiar enough with the codebase or the language to give a good specification. But binary literals should be supported wherever hex or decimal literals are.

Backwards Compatibility

Shouldn't be backwards incompatible.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[alexfertel]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

In my humble opinion, we shouldn't close issues just because they haven't had any activity. This issue is an excellent example of why this policy doesn't work.

[ekpyron]

Is it, though :-)? You could conversely say that this issue is an excellent example of why we need a stale bot.
There is no question that this issue is a valid request. There are no issues with introducing binary literals and they are clearly useful for some purposes. So the only issue here is bandwidth for the actual implementation: we get a lot of feature requests that are equally valid, but we also have limited resources and are trying to work on large agenda items that, longer term, will significantly improve the language overall, compared to which valid feature requests like this one unfortunately have to suffer.
Beyond that we try to reserve github mostly for issues that are fully specified and staged for implementation in a finite amount of time, while for anything else we prefer a discussion in the forum first, which is a good place to collect more community support for a language feature, after which we can make an informed demand-weighted decision on which features we should spend our resources on besides our larger scale roadmap items (unfortunately, not all feature requests can be handled shortly).
A comment, by the way, still counts as activity and the stale bot should be removing the stale label now.

Is that an understandable explanation for the reasoning behind this policy and having a stale bot?

[alexfertel]

Beyond that we try to reserve github mostly for issues that are fully specified and staged for implementation in a finite amount of time, while for anything else we prefer a discussion in the forum first

I wasn't aware of this preference, so I'm sorry to have misused GH issues.

unfortunately, not all feature requests can be handled shortly

I wouldn't presume otherwise or presume this is a critical issue! I didn't mean to make you feel pressured if that was the case.

That being said, the only reason to close this issue would be to make the number of open issues go down, right? As you said, this is a valid request that is clearly useful. Why close it?

Thank you for taking the time to read this @ekpyron and for your effort in improving Ethereum. I just requested to open a topic in the forum regarding this language feature.

[ekpyron]

It's mostly a matter of book-keeping - it's much harder for us to properly organize the issues and our work, if it's not just those issues that we plan to actually implement in the nearer future (we're not at a point in which that's the case for all open issues yet, but we're working towards that). There is also little value in having hundreds (it used to be even a thousand) issues on github, s.t. nobody can ever hope to work through them again and which will only be forgotten and outdated long-term, so that's what we try to avoid.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

[pcw109550]

I nerded out and tried to implement this at #15003.

[pcw109550]

Implementation of binary number literals for solidity is opened at #15046.

[pcw109550]

Implementation of binary number literals for solidity is opened at #15046.

The implementation itself is ready to merge, but we decided not to merge this and close the PR. Reasons:

• No strong demand to this feature
• This diff will add more burden to maintenance

[alexfertel]

I'm sorry that is the case, @pcw109550. Thank you for the fantastic effort, and I'm sorry I couldn't help you. I hope this will get accepted in the future.